Automated solar collector installation design including exceptional condition management and display

ABSTRACT

Embodiments may include systems and methods to create and edit a representation of a worksite, to create various data objects, to classify such objects as various types of pre-defined “features” with attendant properties and layout constraints. As part of or in addition to classification, an embodiment may include systems and methods to create, associate, and edit intrinsic and extrinsic properties to these objects. A design engine may apply of design rules to the features described above to generate one or more solar collectors installation design alternatives, including generation of on-screen and/or paper representations of the physical layout or arrangement of the one or more design alternatives. In some embodiments, metadata about the design process, including the process of classifying features and providing user input, generating layouts, and then modifying those layouts, may be generated. The metadata may include information about exceptional conditions in the project state information or design. A list of exceptions corresponding to exceptional conditions may be generated, and the designer may interact with these exceptions in a variety of ways, such as by complying with rules to remove an item from the exceptions list or overriding the application of the rules. The exceptions may be non-blocking relative to other user actions.

RELATED APPLICATIONS

This application claims the benefit of priority under 35 U.S.C. §119(e)of U.S. Provisional Application No. 61/154,341, filed on Feb. 20, 2009,and entitled “AUTOMATED SOLAR COLLECTOR INSTALLATION DESIGN INCLUDINGEXCEPTIONAL CONDITION MANAGEMENT AND DISPLAY”, which is herebyincorporated herein by reference in its entirety.

STATEMENT OF GOVERNMENT SUPPORT

The invention described herein was made with governmental support undercontract number DE-FC36-07GO17043 awarded by the United StatesDepartment of Energy. The United States Government may have certainrights in the invention.

BACKGROUND OF THE INVENTION

In recent years, solar power has become an increasingly important sourceof energy. Solar energy may be collected and harnessed in numerous ways,including through the use of solar collectors such as photovoltaic (PV)modules and solar-thermal heat and power collectors and converters. Thesize of these projects may vary tremendously—from single-familyresidential rooftops to sites exceeding one million PV modules.

The cost, useful lifetime, energy generation and economic value of solarpower plants is highly dependent on many complex and interrelatedparameters including but not limited to: i) location, ii) weather, iii)physical obstructions that interfere with layout, such as a skylight,iv) non-physical site features such as property line set-backs orutility right-of-ways, v) physical obstructions that may cast shade onthe system, vi) local building codes that set weight limits and firesafety protection, vii) environmental conditions such as design windspeed tolerance, viii) available mounting surface, such as the ground, aroof-top or a framework above a parking lot, ix) local, state andfederal law, x) utility electrical interconnection requirements, xi)existing electrical equipment at a customer's worksite and xii) thecustomer's cost of electricity or energy. The task of designing andanalyzing an efficient system that comports with these requirements canbe complex, time consuming, and error prone, and may constitute a majorcost of solar energy project development.

SUMMARY OF THE INVENTION

A method of generating a solar collector installation design on acomputer is disclosed. The method may include providing a representationof an installation worksite, wherein the representation may includeuser-defined project state information. The method may include applyingrules to the user-defined project state information, so as to determineat least some metadata about, e.g., the solar collector installationdesign. The metadata may also be used to generate a set of one or moredesign exceptions. Each design exception may encode one or moreexceptional conditions. Exceptional conditions may be due to manycauses, including to a violation of a software-encoded rule by theuser-defined project state information, the design, a layout, etc. Arepresentation of the set of design exceptions may be provided to theuser. An option may be included to the user, and the option may includeignoring the exception or complying with the design exception. The usermay or may not be required to address, as by complying with, any of thecorresponding exceptional conditions before performing another action inthe user interface.

A method of generating terms to a contract for a solar collectorinstallation project is also disclosed. The method includes providing arepresentation of an installation worksite in a computing device. Therepresentation may include at least one geometric object, project stateinformation, etc. The method may include applying one or more rules tothe one or more geometric objects and/or the project state informationso as to determine metadata about the installation design. The metadatamay be used to generate a set of one or more exceptions where exceptionmay encode an exceptional condition arising from a violation of a ruleencoded in software and regarding the installation design. Theexceptions may provide information sufficient to identify a term forinclusion in a contract, e.g., a downstream agreement. The method mayinclude using the information to generate a list of the terms forinclusion in a contract or document, where the terms may correspond toone or more contract exclusions.

A computer-based user interface for designing a solar collectorinstallation design is disclosed. The method may include a computeruser-interface representation of a solar collector installation design.The representation may include solar collectors arranged on a surfacesubstantially according to project state information, e.g., featureproperties. A representation of a list of design exceptions may beprovided. One or more of the design exceptions may correspond to anexceptional condition that may be related to a violation of asoftware-encoded design rule by the solar collector installation design.The interface may include a control operable to allow a user to addressthe exceptional condition by interacting with the design exception.Interaction with the exception may include complying with the exception,overriding the design exception, and so forth. In some embodiments, theuser may perform other actions in the user interface before addressingthe exceptional condition.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic isometric view of an example worksite for a solarcollector installation containing roof, exhaust fan, and conduitfeatures;

FIG. 2 schematically illustrates a user interface containing a visualrepresentation of the installation worksite of FIG. 1, includinggeometric objects corresponding to the roof, exhaust fan, and conduitfeatures;

FIG. 3 illustrates the user interface of FIG. 2, in which a firstgeometric object in the visual representation is being classified as a“roof” and thereby associated with a first set of feature properties andcorresponding layout constraints;

FIG. 4 illustrates the user interface of FIG. 3, in which a secondgeometric object is being classified as a “obstruction” with sub-type“exhaust fan” and thereby associated with a second set of featureproperties and corresponding layout constraints;

FIG. 5A illustrates the user interface of FIG. 4, in which an exampleset of design preferences for the generation of a layout, including a PVmodule type, orientation, and starting point, are being input;

FIG. 5B illustrates the user interface of FIG. 5A, in which a PV modulelayout has been generated by a layout engine in accordance with theinputs (e.g., feature properties, project properties and designpreferences) and layout rules (e.g., layout constraints, environmentalfactors, local building codes, etc.);

FIG. 6A is a flowchart illustrating a process by which a PV modulelayout, such as that illustrated in FIG. 5B, may be created using thesoftware of an embodiment;

FIG. 6B illustrates the user interface of FIG. 5A, in which a PV modulelayout has been tiled across a rooftop, in accordance with an embodimentof the first pass of the process of FIG. 6A;

FIG. 7A illustrates the user interface of FIG. 5A, in which a user hascreated a “work area,” one or more contiguous sub-area(s) within theworksite, a graphical representation indicating the owner's preferencefor where modules may be placed upon the worksite. This may occur, forexample, if the worksite contains both undeveloped land and a buildingbut the owner is only interested in placing modules on the building;

FIG. 7B illustrates the user interface of FIG. 7A, in which a PV modulelayout has been generated according to the work area properties, featureproperties, layout constraints, design preferences, and other layoutrules;

FIG. 8A illustrates the user interface of FIG. 5A, in which twouser-created apertures and corresponding user-defined aperture designpreferences have been defined;

FIG. 8B illustrates the user interface of FIG. 8A, in which a PV modulelayout has been generated according to the aperture design preferencesfor each aperture, and in accordance with the project properties,feature properties, layout constraints, and other layout rules;

FIGS. 9A and 9B are flow charts illustrating processes by which PVmodule layouts may be created by a layout engine in accordance withmultiple user-defined apertures, each of which may contain differingaperture design preferences;

FIGS. 10A and 10B schematically illustrate a partial hierarchy of datarepresenting worksite features and solar collectors to be arranged in asoftware application in accordance with the teachings herein;

FIG. 11 schematically illustrates a user interface containing a list ofexceptions, including warnings, errors, and contract exclusions, andvarious mechanisms by which a designer may address such exceptions;

FIG. 12 is a flow chart illustrating a process by which user inputs andresultant layouts may be validated and exceptions may be generated;

FIG. 13 illustrates the hierarchy of project elements of FIG. 10A,expanded to include partial depictions of multiple versions of layoutsgenerated by the software, as may be created in response to userselections of alternative design preferences, aperture locations, etc.;

FIG. 14 schematically illustrates a user interface including a list ofversions for the project design and controls for operating uponversions;

FIG. 15 schematically illustrates a portion of a version summary;

FIG. 16A provides a screenshot of another illustrative user interface inwhich a user may classify geometric objects and in a which to display PVmodule layout, which may be generated according to feature properties,project properties, layout rules, and design preferences;

FIG. 16B provides a screenshot of an illustrative user interfaceproviding toolbar controls for some functions related to classificationand layout of PV modules;

FIG. 16C provides a screenshot of an illustrative user interfaceproviding menu controls for some functions related to classification andlayout of PV modules;

FIG. 16D provides a screenshot of an illustrative user interfaceproviding a palette control for access and modification of featureproperties, design preferences, and other user input; and

FIG. 16E provides a screenshot of the illustrative user interface ofFIG. 10A in which a PV module layout has been generated according to,user inputs (e.g., feature properties, project properties, designpreferences), and layout rules (e.g., layout constraints, environmentalfactors, local building codes, etc.).

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Computer aided design systems (CAD) have been in commercial use for manydecades. CAD systems provide efficient methods to automate the creation,editing, presentation, and retrieval of design information. The power ofCAD systems has been enhanced through the use of “knowledge-based”programming techniques whereby engineering and/or design rules can beformalized, encoded and executed to automate portions of the designprocess or to detect potential design errors. A common example of aknowledge-based system is the grammar checking function found in mostcommercial word processors whereby many rules of English grammar havebeen encoded and are automatically applied to text documents tohighlight potential errors and suggest corrective action.

The systems and methods described herein involve the application ofknowledge-based CAD techniques for the automatic layout, evaluation, andoptimization of solar energy system designs consistent with a largenumber of design constraints, such as the local site conditions,engineering rules, and building codes. A preferred embodiment isimplemented as an integrated set of software customizations to anexisting CAD system, such as AutoCAD®. Alternatively, the systems andmethods described herein may be implemented as completely new standalonesoftware program(s).

A preferred embodiment of the invention described herein provides asystem and method for designing solar collector layouts suitable forinstallation at a given worksite. The embodiment may include systems andmethods to create and edit various data “objects” and to classify suchobjects as various types of pre-defined “features” with attendantproperties and layout constraints. The classes or categories of featuresmay include (i) physical worksite features such as walls, roofs andexhaust fans; (ii) intangible, non-physical worksite features suchproperty boundaries, zoning boundaries, utility right-of-ways, floodplains, environmentally-sensitive areas, special seismic zones, andutility easements; and (iii) solar energy system components andarrangements. As part of or in addition to classification, theembodiment may include systems and methods to create, assign, and editintrinsic and extrinsic properties to these objects. Intrinsic featureproperties include those that are inherent to the object itself, such asheight, weight and cost. Extrinsic properties include definitions of howobjects interact with other objects. An example of an extrinsic propertyincludes a “setback” provision that establishes the minimum distance(setback) between an object and any adjacent objects.

For example, in a particular legal jurisdiction, it may be impermissiblefor a structure to be placed within 30 feet of a property boundary.Using a system according to an embodiment, a user may first create a“Property Boundary” feature type as follows: The user may (i) create anew type of feature class named “Property Boundary,” (ii) set the visualrepresentation of the Property Boundary feature class to be a dashedblack line; (iii) define a property called “Set Back” and assign it tothe “Property Boundary” feature class, (iv) assign a default value, suchas 30 feet, to this feature type; and (v) store this feature classdefinition within a feature class database for use in a particulardesign or for general use in any project design.

Subsequently, a designer may use the pre-defined feature type “PropertyBoundary” as follows: The designer may (i) create or import arepresentation of an installation worksite into an embodiment, (ii)assign the pre-defined type “Property Boundary” to one or more geometricelements in the worksite representation (such as a line), (iii)subsequently change the value of the object's “Set Back” property asnecessary, e.g., to 20 feet, and (iv) command the embodiment to generatea solar system design, including a layout of solar collectors, thatcomplies with the setback provisions of the objects marked as “PropertyBoundaries.”

As part of the process of generating a solar collector layout, apreferred embodiment of the invention may provide methods and systemsfor the (i) creation of design rules, (ii) application of these designrules to the objects described above to generate one or more solarenergy system design alternatives, (iii) generation of on-screen and/orpaper representations of the physical layout or arrangement of the oneor more design alternatives, (iv) generation of summaries of one or moreversions of one or more designs, such as part count, capacity, cost andenergy production, (v) tracking of exceptions to software-encoded designrules for user compliance or the manual modification or override of suchdesign rules as a mechanism to provide both flexibility to the user andassurance that customer, engineering, legal, and manufacturerrequirements are addressed, and (vi) generation of visual informationfor the designer to enable them to assess, in real-time, the relativebenefit of design alternatives and design modifications to assist indesign optimization.

A method of operation according to a preferred embodiment includes: (i)importing information describing the worksite into the knowledge-basedsolar CAD system or the creation of this geometric description using theCAD system; (ii) associating, as by classifying or categorizing, each ofthe relevant graphical elements that describe the worksite as one ormore instances of pre-defined data object types and adjusting theirrespective properties; (iii) designating “work areas,” e.g., areas ofthe worksite where project layout may be intended; (iv) choosing designpreferences, such as solar collector type and installation size; (v)automatic design generation according to the feature classificationsdefined in the data representation of the worksite and their attendantproperties; (vi) evaluation of the design according to one or moremetrics; (vii) generation and comparison of design alternatives; (viii)optimization of a design through design modification and selection ofalternatives; and (ix) generation of a list of design exceptions, suchas contractual exclusions.

Association may be performed by classifying particular geometricobject(s) in a representation of a worksite as an instance of a type offeature, such as “roof” or “exhaust fan.” Such classifications mayoperate to associate the geometric objects with specific properties andlayout constraints used to perform the automatic solar energy systemdesign. Additional design rules and properties relating to worksiteproperties and layout constraints, design preferences, module propertiesand constraints, performance targets, and so forth, may also be defined.All of this encoded information may be used by the tool to automaticallygenerate a design for the solar module installation that is consistentwith designer preferences, project constraints, engineering practice,building codes, etc., and to produce associated information, such aswiring schema, bills of material, presentations, contracts, summaries,auditing reports, other deliverables or outputs according to Table I,etc.

As mentioned above, a tool may also provide control over layoutgeneration by providing a designer with the ability to define one ormore particular boundaries for layout generation. Users may define oneor more work areas that may correspond to boundaries within which solarcollectors may be placed (consistent with other properties and rules,e.g., the properties of classified objects). In this way, a user may usea work area, e.g., to limit solar collector module layout to a portionof the worksite, such as the south facing portion of a roof. Users mayalso define one or more layout apertures, each of which may correspondto boundaries in which layouts should comply with a distinct set ofuser-defined design preferences. The use of apertures with distinctdesign preferences may allow a user, e.g., to place one type of modulein one region of a roof and another type of module in another region ofa roof.

In some embodiments, as a designer goes through the process ofclassifying features, generating layouts, and then modifying thoselayouts, as discussed above, metadata about the design process may begenerated. This metadata may take many forms, and may includeinformation about actions the designer has taken, actions the designershould take, and design information that may be useful to supervisors,co-designers, and downstream users and recipients of the design.

In some embodiments, a user interface may be provided such that some orall of this metadata may be presented to the designer in the form ofexceptions to encoded rules in the software. Such rules may originatefrom customer requirements, governmental laws and regulations,engineering constraints, solar collector manufacturer guidelines, etc.Exceptions can include the failure to provide properties, such as aproject work area location. The designer may interact with theseexceptions in a variety of ways, such as by complying with rules toremove an item from the exceptions list or overriding the application ofthe rules. Some or all of the metadata may be associated with thedesign, such as by common storage or reference. Thereafter, downstreamusers and processors of the design, including automated systems, mayaccess the information. The information may also be summarized,exported, translated, or otherwise operated upon by the system. The listof exceptions may serve as a “To Do” list (and may be named as such in auser interface) for the user, affording the user flexibility in themanner and sequence in which the software rules are addressed while atthe same time providing assurances that they do get addressed. Theexceptions and how they were handled can also be maintained in a historyfor later review, and can aid in ensuring that contract documentsreflect unusual or non-standard choices.

Some embodiments may provide a system and user interface for viewing,creating, and manipulating multiple versions of a solar collector layoutdesign for a particular installation worksite. The use of versions mayallow, for example, a designer to quickly and easily change inputs(e.g., design preferences and/or feature or project properties) and viewthe resultant outputs (e.g., alternative layouts, cost and performancedata) that correspond to the alternative design choices (e.g., the costimpact of using various types of PV modules) for the same project. Theseversions may provide the designer with the ability to rapidly modeldifferent layouts based on changes in user inputs and evaluate theresults. Some embodiments may allow the designer to quickly move fromone version to another, while others may allow a designer to affectmultiple versions with one action. Versions may share one or more setsof elements, properties, or design rules, such that changes made to oneversion apply to related versions. For example, generic changes to aworksite, such as the addition of a newly discovered site feature, mayaffect multiple design versions. The versions may share information, by,for example, being located in a single, e.g., composite, file.

1. INTRODUCTION

Concepts described herein are applicable to solar energy collectorinstallations generally. Various types of solar energy collectors, suchas panels, absorbers and reflectors, and other energy conversiontechnologies, such as photovoltaic (PV) modules, solar-thermalabsorbers, and concentrating solar power (CSP) solar systems, may beused. Solar collectors may be self-mounted or placed on mounting systemsof various types, including tilted, fixed, and tracking systems. Systemsmay be designed for on-grid connection to public utilities and/or foroff-grid systems. Solar collectors and mounting systems may be attachedto or located on variously the ground, rooftops, walls, parkingstructures, and so forth. For ease of exposition, embodiments are hereinlargely discussed in connection with PV module installations. It will beunderstood, however, the embodiments are applicable to solar collectorsgenerally and as described above.

The task of designing a PV installation typically includes severalnon-trivial and co-dependent processes. These processes include, forexample, (1) selection of particular PV modules based on, e.g.,availability, cost, efficiency, power requirements, etc.; (2) generationof a placement (layout) of PV modules at an installation worksite; (3)generation of a wiring (routing) scheme for the placed PV modules; (4)estimation of project outputs, including power production, powerconversion efficiency, etc., based upon complex and project-specificinputs; (5) generation of downstream documents, such as project bills ofmaterial (BOMs), contracts, etc. Of course, all of the foregoing must bedone in compliance with local regulations, national regulations, etc. Asequence of typical steps performed in a large-scale solar project isprovided in Table II.

As the size of an installation increases, as measured, e.g., by modulecount, the difficulty of performing the above processes increases. Evenostensibly trivial changes, such as adding a module in a given a row,can have far-reaching impacts on wiring topology and/or the placement ofother modules, and, therefore on the resultant system design and outputsof the system (such as power output). Moreover, because of suchcomplexity, the optimization or modification of layouts, includingre-arranging, adding, or removing modules, can be difficult and,especially for large projects, can begin to resemble a process oftrial-and-error. By the time a project is designed, which can often taketen to twenty weeks, or a contract finalized, which may take many moremonths, the originally-contemplated components used in the layout mightnot be available and significant redesign may be required.

Some of the tedium and complexity of creating a design for a worksitecan be reduced through the use of automated tools. In particular,software or otherwise computer-implemented tools are described hereinthat may automatically generate a design for a worksite based uponencoded information corresponding to engineering practice, designerpreference, and worksite conditions. Some such tools will use as astarting point a CAD representation of an installation worksite, e.g.,an AutoCAD .DWG file. This file may include a vector or bitmaprepresentation of a worksite, which may typically be represented as acollection of geometric objects, such as lines, polylines, curves,squares, rectangles, splines, symbols, polygons, other 2D or 3D shapes,surfaces, solids, image data, etc. This representation may typically nothave much or any semantic information attached to the geometric objects;in particular, the information in this representation may be limited toshapes and dimensions corresponding to features of the physicalworksite. So, for example, a 2D plan view representation of a roof withan exhaust fan might consist of a set of four lines forming a largerectangle (the roof) and another set of four lines forming a smallersquare (the exhaust fan) where the smaller square is contained withinthe large rectangle. Conventional tools for CAD, as well as someembodiments, may provide the ability for the user to create this initialrepresentation of geometric objects. Alternatively, the user may importit from a storage location, such as a computer file.

Some embodiments may provide a mechanism by which objects in therepresentation may be classified (e.g., categorized or tagged) so as toassociate the object with semantic information relevant to generating amodule layout, such as feature type. For example, a set of lines may beclassified by a user as an instance of the pre-existing feature class of“roof”. The system may use this classification to associate the objectswith a set of semantic information corresponding to the relationshipbetween a roof and a module layout. This information may be related tothe intrinsic physical properties of a roof, such as “pitch=17 degrees”and “height=30.0 feet,” and/or extrinsic properties of a roof (such as“edge setback=1.0 foot”). Such properties typically may be editable bythe user and may vary across different instances of the same generaltype and by legal jurisdiction (zoning laws, etc.). An example list offeature classes is provided in Table III; an example list of featureproperties is shown in Table IV.

Similarly, another object (or set of objects) in the worksiterepresentation may be classified by the user as an instance of thefeature type “exhaust fan.” The system may thereafter associate theobject with feature properties corresponding to a exhaust fan, such as“height=3 feet.” In some embodiments, a virtually unlimited number ofobjects may be classified as different types of features with differentproperties. For some of these various features, feature properties maybe categorically pre-determined (and thus applicable and invariant toeach instance of a particular class or type) while other featureproperties may merely have default, instance-specific values. Manyfeature properties, such as height, may be adjusted by a user asnecessary and/or expedient, while other types of feature properties,such as those that are relevant to the entire feature class, may or maynot be editable by a user. As such, each classified object may havefeature properties shared with and/or distinct from those of otherclassified objects.

The semantic information associated with a particular object may alsocorrespond to generalized design rules that may typically be invariantfor all instances of the particular feature class. For example, objectsclassified as roofs may generally be associated by the system withappropriate feature layout constraints, such as “collector layoutallowable=yes,” and other design rules relating to how modules may beplaced on or around a roof. As discussed below, in some embodiments,design rules may be overridden at least during initial use of thesoftware, but a list of exceptions maintained to track any variancesfrom the rules' requirements.

In this way, through the classification actions of the user, theoriginal, simple geometric representations of objects may be assignedadditional, e.g., higher-level, feature information to be used by theautomatic design system. In addition, the system may provide a mechanismby which objects are automatically classified as instances of featuresand by which values are assigned to feature properties and designproperties. A shape-recognition algorithm, learning algorithm, or otherexpert system may be used to classify objects and assign values. Inaddition, geometric objects may be modified, e.g., repaired, as by apre-processing stage, to place the objects in a better condition orposition for classification, feature assignment, or layout processing. Arepair engine may also use input from a designer, e.g., an attemptedclassification, as a basis for repairing objects. For example, if adesigner attempts to classify four lines as a “roof,” but the lines donot form a fully-closed shape, a software repair engine may attempt torepair the objects, as by making the appropriate lines co-terminal.

Some embodiments may provide a layout component, such as a layout enginesoftware module, that uses the classified objects, their classificationsand encoded information, e.g., the set of feature properties, andpossibly other information as described below, to create a moduleinstallation design. So, for example, because an object classified as a“roof” may be associated with the layout rule of “layout allowable=yes,”a layout engine may know that it may consider placing solar collectorsin the bounded area between the classified objects marked as forming a“roof” Similarly, the layout engine may know not to allow placementmodules in the area corresponding to objects marked as “exhaust fan,”because exhaust fans, as a class or as a particular instance, may beassociated with the layout rule of “layout allowable=no.” As such,objects that potentially allow placement of modules within them, such asroofs, may be referred to as creating implicit “work areas” in whichmodules may be placed (consistent with other layout rules), such thatseparate user definitions of a work area may not be needed.

A user may also be provided with mechanisms to assert even greatercontrol over the layout process. For example, a user may be allowed torefine the boundaries of acceptable module placement by, e.g.,explicitly defining one or more user-created work areas. A user-createdwork area may be a geometric object created by the user and associatedwith a particular set of layout rules, including, for example, “layoutallowable=yes.” A layout engine software module thus may be configuredto consider placing solar collectors only in locations that arecontained within an explicit, e.g., user-created, work area, an implicitwork area, either, or both. This may be useful, for example, if adesigner wished to limit solar collector layout to only a portion of aroof, which could be accomplished by creating a work area over only thedesired portion of the roof.

A user may also be allowed to specify different design preferences, suchas module type or orientation for the solar collector layout, and,moreover, different choices can be made to apply to different areas ofthe representation. Table V provides an illustrative list of sampledesign preferences. So, for example, a user may be allowed to define aboundary wherein a particular set of design preferences is applied e.g.,by defining one or more apertures. An aperture may be a boundary orframe represented by a geometric object created by the user. The systemmay associate the aperture with a set of design preferences, including,for example “PV module=SD305” and/or “tilt=45 degrees.” A layout enginemay be configured to place solar collectors, e.g., PV modules, withinthe boundaries of a given aperture consistently with the aperture'sassigned design preferences and the relevant feature properties, layoutrules, and other applicable properties and design rules. In some cases,a user may define more than one aperture, and, thus, the layout enginemay use varying sets of design preferences for layouts in differentareas of the worksite. Distinct apertures may be useful, for example, ifa designer wished to place one type of module, e.g., SD305s orientednorth-south, in one area of a roof and another module, e.g., SP225soriented east-west, in another area of the roof. As another example,multiple apertures may provide heterogeneous layouts for the purpose ofdefining different spacings between rows of modules in different regionsof a work area. According to some embodiments, a layout of solarcollectors may be generated in any allowable solar collectorinstallation region within (e.g., only within) a work area and within alayout aperture according to the aperture's design preferences regardingplacement of solar collectors and the properties of any objects andfeatures, and the layout rules or constraints associated therewith. Thelayout may take into account collector modules and other objects andfeatures that are outside a work area or aperture if, for example, thedesign preferences and properties of the objects are such that setbackscall for it. For example, an object such as an exhaust vent may bewholly or partially outside an aperture, but if the application ofdesign preferences restricts the layout of modules within a meter of thevent, and the exhaust vent is sufficiently proximate to the aperture orwork area, then that exhaust vent may be taken into account.

In some cases, apertures as defined by the user might overlap orotherwise interrelate with each other. In such a case, aperture conflictresolution rules may be utilized. For example, a conflict resolutionrule may define Aperture 1 as taking priority over Aperture 2. A layoutengine may thus give modules placed in accordance with Aperture 1priority over those placed in accordance with Aperture 2. This may beuseful, for example, if the designer defines apertures with overlappingboundaries, or if a designer wished to place solar collectors, e.g., PVmodules, on both sections of a concave roof (i.e., the facing walls ofan inverted or “V”-shaped roof). Because collectors and their mountingstructures may have significant height, there may be a conflict inmodule placement at the intersection of the two roof section (i.e., thebottom of the V). If one roof section receives more sunlight than theother, the designer may wish to define an aperture for the sunnysection, and an aperture for the shady section. The user may be allowedto assign priorities to the two apertures, such that, in the event ofconflict, the layout engine will place modules according to the designpreferences of the sunny aperture over the design preferences of theshady aperture. This may result in a net increase in the averageper-module power generation for the installation. A default priority maybe assigned to apertures, for example, in accordance with the sequencein which the user defines the apertures or an explicit priority.

The results of a design, including layout, may be displayed, saved,printed, transmitted, or otherwise utilized. Additional informationpertaining to the layout, such as bill of materials, a rendering, afinancial analysis, a contract, a contract term, an energy projection, acost analysis, a parts list, a simulation, a project schedule, anavoided cost analysis, a presentation, a term sheet, and so forth, maybe generated based on the encoded information and generated layout.

Software controls to perform the foregoing actions may be included aspart of CAD software. Alternatively or additionally, a specializedengine, library, or plugin may be loaded into the CAD software atstartup or on demand. Alternatively, a specialized or new softwareprogram may be written dedicated to the implementation of embodiments ofthe invention. Many mechanisms for creating, selecting, and operatingupon objects in a CAD software environment are well-known in the art;such mechanisms include, for example, click-select, drag-select,shift-select, clicking and right-clicking on icons, toolbars, popups,objects, and so forth. Joe Sutphin's “AutoCAD 2006 VBA: A Programmer'sReference,” 101 Productions (2005), ISBN 9781590595794, which disclosesmany such methods, is hereby incorporated by reference in its entirety.

2. SYSTEM OPERATION AND USER INTERFACE

FIG. 1 provides a schematic illustration of an installation worksite forwhich a solar collector layout will be designed. For convenience, theembodiments discussed herein use photovoltaic (PV) modules as examplesof solar collectors. PV modules are to be placed on the roof 101 of abuilding 100. The roof 101 may have a set of physical features, such asexhaust fans 102, conduits 103, walkways, pipes 105, large HVACappliances 104, skylights, elevator machinery, stairwells, and so forth.When projected geometrically onto the roof 101 (as in a top-downbirds-eye view), features may appear solid/two-dimensional (such asexhaust fans 102) or linear/one-dimensional (such as conduit 103)relative to the roof. A given feature may have a regular footprint on aroof, such as the rectangular footprint arising from an exhaust fan;alternatively, features may have an irregular footprint. Features of aroof may also be intangible, such as areas 106 of high wind or updraft.The roof 101 and each feature upon it or relating to it may have a setof characteristics relevant to solar collector installation design. Forexample, PV modules are not typically placed on an exhaust fan or withina prescribed setback from an exhaust fan 102, where the setback may bedetermined by regulation, customer policy or design choice. Similarly,PV modules typically are not placed in areas of high wind 106, or withina certain distance of an edge or corner of the roof 101.

The features of a roof may also determine the relative performance of PVmodules placed on the roof 101. For example, presuming that the roof 101is most typically exposed to sunlight from the South (indicated as 105),a PV module placed at a location A is likely to generate more power, onaverage, than a PV module placed at location B (which is at leastpartially obscured by a large HVAC appliance 104).

FIG. 2 illustrates the installation worksite of FIG. 1 as represented inan example user interface of a computer-aided design (CAD) system 200.The CAD system 200 may include a 2D or 3D visual representation of theinstallation worksite. Typically, the representation includesthree-dimensional information about the features of the worksite. Forconvenience, the embodiments are described with reference to a 2D planview 204. The visual representation may be constructed of geometricentities, such as lines, line segments, polylines, arcs, curves,circles, square, rectangles, polygons, etc. These geometric entities maybe closed, meaning they define a bounded area, open, orself-intersecting, may be planar or non-planar, and may include holes,complex surfaces, and geographic topography. These geometric objects maycorrespond to physical or non-physical features at the physicalworksite. For example, the representation 204 provides two polygons eachdefining bounded areas referenced by numeral 202 corresponding to theexhaust fan features 102 from FIG. 1. A set of line segments and curves203 corresponds to the conduit feature 103 from FIG. 1. The visualrepresentation may first be loaded into the CAD software through the useof a particular file format, such as AutoCAD .DWG. Alternatively, thevisual representation may be created in the CAD software through the useof standard CAD drawing tools. The visual representation 204 in the CADsoftware may represent only a portion of a worksite or representingareas beyond the worksite.

At this point, the representation of the worksite in the CAD softwaremay have very little semantic information attached to it. For example,other than mere geometry, the four line segments that form each of thebounded areas 202 may not be associated semantically with, or otherwisehave meaning in relation to, the corresponding exhaust fan features 102.Characteristics of an exhaust fan feature relevant to PV module design,such as typical setback or the shadows it may cast (e.g., is expected tocast) at different times of day or year, might not be incorporated inthe representation. Similarly, the lines 201 corresponding to theoutline of the roof might not be associated semantically in the CADsoftware with the roof 101 of the worksite. Rather, from the perspectiveof the CAD software, the visual representation may simply be acollection of geometric objects with dimension information only, removedfrom semantic relation to each other, the external worksite, or solarcollector installation design. Alternatively, the representation mayhave some semantic information attached to objects, such as, for exampleGPS data. This data may be used in subsequent steps in the process.

FIG. 3 illustrates a process by which the visual representation and thegeometric objects within it may be given semantic meaning. Aclassification component of an embodiment may perform this action byallowing a “dumb” geometric object, e.g., one having dimensionalinformation only, to be classified, automatically or by the user, as aninstance of a particular type of feature. As part of classification asan instance of a class of feature, an object may be associated with aset of additional feature properties, which may include properties ofthe feature that may pertain to solar collector installation design,such as height, setback, etc. The classification and properties may beused by the system to associate the object with layout rulescorresponding to potential interactions between the classified objectand other objects and impact on a resulting solar collector design.These feature properties may be recognized, utilized, and operated uponby software, such as a layout engine that applies layout rules toobjects.

So, for example, polyline 201 may be associated with a type of feature,such as “roof” This classification may implicate layout rules relatingto the placement of PV modules on roofs. These rules, when invoked by alayout engine, may operate on feature properties of the particular roof(e.g., a vertical height off the ground and roof pitch). The propertiesassociated with an object may be determined by correspondence orinterrelation with other object properties. So, for example the heightof an exhaust fan relative to a roof (which may be useful forcalculating the shadow cast by the exhaust fan on the roof) may bedetermined from feature properties describing the absolute maximalaltitude of the exhaust fan and the absolute height of the roof at thepoint of the exhaust fan (which itself may be determinable by the roofsproperties of height and pitch). In this way, the encoded information,including object classifications and feature properties, may form (or beassociated with) a complete or partial specification of thecharacteristics of the physical features of the installation worksite asthey relate to PV module layout design. In particular, thecharacteristics of the physical feature related to solar collectorlayout design may include or form at least a partial set of informationfor the automatic placement of solar collectors within or around thatphysical feature. Pre-defined feature classifications and classes mayinclude physical features and non-physical features, such as a propertyboundary, a real-estate parcel boundary, a zoning designation, a utilityright-of-way, a flood plain, an environmentally-sensitive area, or aspecial seismic zone.

In particular, some geometric objects may be classified as instances offeatures types that provide allowance for placement of PV modules, e.g.,a geometric object classified as a roof may be associated with a layoutrule that generally allows placement of PV modules on its surface. Assuch, the classification of an object as a “roof” may cause that objectto be treated as an implicit work area. Similarly, some geometricobjects may be classified as features that prohibit, or otherwise do notgenerally allow, placement of PV modules, e.g., a geometric objectclassified as a pond or an air conditioning unit may be associated witha layout rule that generally does not allow placement of PV modules onthe obstruction or within a prescribed boundary, e.g., distance, of theobstruction. Other layout rules to be imposed on the placement of PVmodules may be defined, including constraints embodying the applicationof construction regulations and codes, wind conditions, temperatureconditions, power and heat generation limitations to module placement onor nearby a given feature.

The form and content of the feature properties associated with a giventype of feature may precede or pre-exist the creation of a correspondingobject. Classes of physical features, and the encoded informationcorresponding thereto, may be predefined. So, for example, the set ofproperties and default values corresponding to a roof or other surface,and the design rules that apply to them, may be stored in a databaseand/or as part of a class definition. (See Tables III-IV.) When aparticular object is classified as a roof, the class definition may beinstantiated and associated with the particular object. Of course, thesoftware may provide a mechanism whereby additional types of featuresmay be defined by the designer and used for classification. Similarly,the default or pre-existing encoded information, including defaultvalues for properties and layout constraints, for a given type of objectmay be modified by designers or administrators. Modification of theencoded information may take place before generation of a layout and/orafter generation of a layout. Modification of certain encodedinformation, such as feature properties, after generation of a layoutmay trigger automatic regeneration of the layout based upon the new setof data. Some implementations may allow the creation or modification offeature classes at the time of categorization. For example, the userinterface may present the above-described capabilities integrated intoor accessible from the classification interface components.

The mechanisms or user interface controls by which objects areclassified, modified, or otherwise associated with properties may vary.For example, as shown in FIG. 3, a user may select the polyline 201corresponding to the roof 101. The user may then click upon a “Roof” or“Classify As . . . ” toolbar button or icon, or select similar commandsfrom a menu. The user may also right-click with a pointer tool on thepolyline 201 to simultaneously select the polyline 201 and open acontext menu 310 that allows classification as a roof. During selectionand classification, the representation of the object may be changed toindicate its selection or classification. For example, its color may bemodified, its line weight or style may be changed (as indicated here bythe dashed polyline 201). Many types of controls for performing actionsupon objects in a user interface are well-known in the art. Multipleobjects may be classified as instances of the same type of feature, suchas a “roof,” which may allow the system to create layouts for worksitescontaining multiple roofs. Different types, or subtypes, of features maybe represented differently, such as being placed on distinct drawinglayers in the user interface and/or may be given different colors orline weights. A control to declassify an object may be provided.

Mechanisms for automatically repairing invalid or deficient worksitegeometry may be employed. For example, suppose that, in one embodiment,the design rules require that a “roof” be represented by a closedpolygon. Suppose further that the geometric information corresponding toa roof in a worksite representation is composed of four line segmentswhose common endpoints are in close proximity but are not coincident(i.e., not forming a closed shape). This geometrical representation maycause a processing error or produce incorrect results if the lineendpoints are left non-coincident. In one embodiment, a mechanism may beprovided to pre-process geometric elements during classification, forinstance, to transform line segments with non-coincidental endpointsthat are within a specified degree of closeness to each other into linesegments with shared end-points. Geometric algorithms for repair ofnon-semantic geometric data exist.

The software may also provide controls to allow a user to see and/ormodify some or all of the encoded information, such as editableproperties, associated with a given object. So, for example, the userinterface may include a properties roll-up, toolbar, or palette 311 thatshows representations of some or all of the feature propertiesassociated with that object. Some feature properties, such as verticalheight 312 for a roof, may be adjusted by the user. Other featureproperties, such as the resulting area, e.g., in square meters, of theroof that may be used to place PV modules may be calculated by thesoftware, e.g., dictated by the interaction of layout constraints,feature properties, and so forth. Other information, such as anindication of the layout rules applicable to a given object, e.g. aindication that a particular object is suitable for placement of PVmodules, might not be displayed or visible to the user. Many types ofcontrols for modifying the properties of objects in a user interfaceexist.

Some embodiments may include a hierarchy of feature classes. Forexample, features may be divided into three main categories: placeablesurfaces, solid obstructions, and linear obstructions. Each category mayinclude several types of feature. For example, placeable surfaces mayinclude roofs, fields, walls, etc. Solid obstructions may includeexhaust fans, poles, HVAC units, depressions, trees, roof hatches,antennas, satellites, stairs, drains, penthouses, roof shot, skylights,sleepers, survey points, vents, valves, etc. Linear-type obstructionsinclude walkways, equipment, expansion joints, walls, conduits, pipes,etc. Each type of feature may also contain subtypes, e.g., an antennaobstruction may be sub-typed as an outline antenna, a point antenna,etc., and a conduit may be sub-typed as an electrical, water, support,vertical, etc. conduit. Some obstructions may be classified as eithersolid or linear, depending on the specific geometry (e.g., a set ofstairs).

Similarly, FIG. 4 illustrates a process by which a second object may beclassified to associate it with semantic meaning. Here, the set of linesor polyline 202 corresponding to an exhaust fan on the roof is beingclassified as a solid obstruction, viz., an “HVAC unit” of subtype“Exhaust Fan,” through the use of a context menu 310 and propertiespalate 311. Here, the dashing of the line is used as a visual cue to theuser that this particular object has been selected. Properties palate311 shows sample relevant feature properties and their current valuesfor the exhaust fan, including height, setback, subtype, etc. The palate311 shows that the object 202 in FIG. 4 has been classified as a featureof category (or class) solid obstruction 315, type HVAC 317, and subtypeExhaust Fan 319. In this way, multiple objects corresponding to thephysical installation worksite may be classified. In some arrangements,rather than requiring a user manually to classify objects as illustratedabove, a system initially may attempt to auto-classify objects basedupon, e.g., heuristics and analysis of the representation of theworksite or metadata already available, e.g., objects in a pre-made CADdrawing layer named “skylights” may be auto-classified as skylights. Asystem may allow or require later modification or verification by auser. A system may use any information related to the geometric objects,such as GPS data, to auto-classify objects.

Not all properties need be associated with a particular feature orgeometric object in the representation. For example, the software mayallow the use and setting of global project properties, such as worksitelocation (zip code), orientation of the worksite (north arrow), drawingscale, units of measure, country location, customer information(customer name, address, etc.). Project properties may include customerproperties, including contact information, legal status, financialcondition, utility information, utility rate, and energy consumption,and may be pre-defined. Other project properties may include soil type,weather conditions, design temperature, design seismic load, operatingcharacteristics, load limits, and electrical interconnectionrequirements, and so forth. This information may be input manually bythe designer or may be accessed through a link to an external datasource such as a Customer Relationship Management (“CRM”) system used tohold the customer account information. Table VI provides an exemplarylist of project properties. Similarly, some design rules, such asproject design rules, e.g., global layout rules, may operateindependently of any particular feature, such as electric powerinterconnection standards that regulate the interconnection of any PVsystem to a public utility. Pre-defined project design rules may form aspecification of an electrical code regulation, a property setbackrequirement, a safety requirement, a interconnection requirement, anengineering rule or best practice, a fusing requirement, etc. Suchregulatory rules may be adapted to produce a layout that may beconnected to a public utility grid, a private electrical grid, oranother specification.

The type(s) of module used in a design may also affect how the layoutengine operates, because module types may be associated with particularmodule-specific information, such as module properties, e.g.,inter-module spacing, voltage, wiring requirements, weight, etc. Somemodule-specific information may be associated with particular types ofmodules, mounting systems, inverter types, and so forth. Differentmodule design rules may operate on a per-module, per-module-string,and/or per-module-sub-array basis. So, for example, a particular modulemay require a minimum inter-module spacing and operating temperature ora particular wiring configuration, such as the number of modules perstring as a function of temperature. Table VII provides an example listof module properties.

As shown in FIG. 5A, design preferences, including the type(s) ofmodules 502 and/or mounting systems to be used, the orientation 503 inwhich to lay out rows and columns of the modules, the start point 504(or origin) of the tiling layout, inverter type (where there areoptions), etc., may also be specified. The user may be provided with theability to modify one or more of the operative global properties, designpreferences, and/or module properties. For example, orientation ofmodules with respect to true north, may be entered numerically into anappropriate control, as shown at 503. Alternatively, orientation may beset by selecting an existing line, such as the edge of a roof top, andindicating module orientation should equal the selected line. A startpoint for layout may be set by, e.g., entering coordinates into anappropriate control 504 and/or selecting a point in the visualrepresentation with a pointing device like a mouse or touch screen, asshown at 506. A control, such as a context menu 520, may be provided toinvoke a solar collector installation layout engine. At the time ofspecifying design preferences, it may also be possible to define newtypes of those preferences which consist of enumerated types, such assolar collector modules, mounting systems, or inverter systems. Thesenewly defined types are advantageously added to the store of definedtypes and are available for use during specification.

As shown in FIG. 5B, the layout engine may be invoked so as to generatea solar collector design based upon, and consistent with, the relevantencoded information, such as feature classifications, featureproperties, work areas, design preferences, global properties, moduleproperties, layout and design rules, etc. In the case of PV modules,this layout may include a physical arrangement of PV modules, asdisplayed in the representation, and an attendant arrangement of wiringsystems, mounting systems and hardware, electrical components for theproper operation of the installation, etc. In some cases, PV modules maybe placed in such a way as to be consistent with all (or substantiallyall) the rules and constraints for all the objects. A number ofdifferent methods and systems may be used to create such a PV modulelayout. In particular, a layout engine component of a system may createa layout using a tiling algorithm.

Under one such algorithm, as illustrated by the flowchart of FIG. 6A, arepresentation of a worksite, including any geometric objects, may firstbe defined (605) by gathering data on physical features (particularlydimension) at the worksite. This may be done at the worksite through theuse of a GPS based surveying device, or, alternatively, CAD software maybe used to create representative geometric objects. This step may beinterleaved with step 610. At step 610, the objects in therepresentation may be classified as features and appropriate values maybe set for feature properties. This may be done either manually by auser or automatically by the system through automated featurerecognition. The user may classify one or more objects as features thatprovide regions in which layout of PV modules is allowed or preferred,such as fields or rooftops. At step 612, the user may specify one ormore work areas, e.g., regions where PV module layout is preferred apriori, as by instructions from the owner. Explicit definitions of workareas are optional and are discussed further below. At 615, designpreferences, project properties, and other encoded information, may beset or modified.

At 620, PV modules may first be tiled across one or more work areas,e.g., objects that are known to be “allowable” for placement, such asrooftop surfaces, without regard to obstructions or other interferingfeatures (like exhaust fans). This may be operationalized, for instance,by placing PV modules across implicit work areas, e.g., across objectsclassified as features that support PV modules. The tiling may beperformed by creating a grid or array in the defined space according tothe relevant module design rules and properties. The tiling may beparametrically varied to include spacing between rows, or the amount ofoffset between adjacent rows or along regular or irregular edges such asa curving road or a property line. Additionally, the tiling maycorrespond to individual modules (with various individually-specifiedlengths or widths) or may represent collections of modules in arbitraryarrangements (e.g. as modules connected to the same mounting structureor tracking mechanism). Additionally, periodic interruption of tiling toaccommodate service roads, mandatory fire access, or other types ofdesign rules may be specified. In some embodiments, geometric objectscorresponding to the module objects of the layout may be actuallycreated and placed in the visual representation, as shown in FIG. 6B.Alternatively or additionally, the layout may be logical, in thatmodules are represented in a data structure. In either case, thegeometric objects may be classified as instances of the relevant moduletype, with the particular feature properties and layout constraintsassociated therewith.

Returning to FIG. 6A, at 625, the system may then make a second passover the tiled modules, marking as illegal any module whose placementconflicts with one or more design rules as applied to properties. So,for example, as shown in FIG. 6B, the entire surface of roof 201 may betiled with modules. A second pass may then consider each module in turnand mark any modules that are placed illegally (i.e., not according tothe rules of the representation and objects). This may beoperationalized, for instance, by looping through each placed module,and, for each placed module, looping through all design rules, andapplying relevant ones to find any conflicts. Thus, for example, anymodules that are within the physical footprint of an exhaust fan 202, orwithin the setback footprint from the exhaust fan 202, may be markedillegal. Similarly, any modules within a certain distance of a high windzone, e.g., FIG. 1 at 106, may be marked illegal. Illegal modules may begrayed out, automatically removed, moved to another layer, or otherwisechanged relative to “legal” modules in the data structure. Marking maybe explicit, as in an “illegal?” field or property in a software datastructure, or may be implicit in the operation of the process. Illegalmodules may or may not be left accessible to the user. Different levelsof illegality may be maintained: for example, some modules may bestrictly illegal, such that a designer cannot override their removalwhile other modules may be “softly” illegal or disfavored, such that adesigner may be allowed to restore their placement. Different levels oflegality may be maintained through the use of distinct colors, layers,and so forth. The result of the layout process is a PV module layoutconsistent with the design rules and properties for the worksite. Asshown in FIG. 5B, the modules laid out at 530, illustrated in solidhatching, are legally placed. There are no modules located in the areareferenced by 533, since that associated area is within the physicalboundaries of an obstruction. The system may include the ability toselect one or more otherwise-illegal modules and restore them to regularplacement. In some cases, this may be performed in contravention of atleast one of the rules as applied to the feature properties. The moduleslaid out at 535, and illustrated in grayed hatching, may be softlyillegal, as they may violate an optional setback requirement. Asdiscussed below, a designer may be allowed to “turn on” or reinstatesuch softly-illegal modules.

Some module placements may be illegal regardless of relationship withany other modules, such as where a module is placed too close to anexhaust fan. However, some illegal configurations may only be apparentrelative to other modules and may therefore be identified recursively.For example, most grid-connected PV installations call for apre-determined number of modules to be wired in electrical series. Forexample, when SunPower™ 305 modules are used in Northern California andconnected to a 600 VDC inverter, exactly 12 modules must be connected ineach series string.

As such, after eliminating “strictly” illegal modules, the system mayperform additional “passes” of the remaining modules to perform arecursive or regressive check for additional modules that may faildesign rules, such as inter-module connection rules. Such modules may begrayed out as in FIG. 5B.

Returning to FIG. 6A, at 630, after automatic generation of a layout,the user may be presented with an option to modify at least one of theobjects or the project generally. User-interface controls to allow auser to modify placement are varied: Illegal modules may be placed on aseparate layer of the representation and/or colored or styleddifferently, as in FIG. 5B. A user may change the layer of an illegalmodule to make it legal, or vice-versa. A user may right-click orotherwise select a module to change its status. A control may beprovided to allow deletion of a legally-placed module, which may includeabsolute deletion or moving the module to a “deleted” layer. A deletedmodule may subsequently be restored if necessary. Controls to undo anaction, or to redo an undone action, such as reinstatement of a module,may be provided. Undo and redo are discussed further below.

Controls may be provided to include the ability to change rules orcategorizations and re-do the automatic layout. A modification componentof a system may provide a user interface, or other mechanism, thatallows replacement of a tile that had been placed but subsequentlyremoved (e.g., according to a rule violation). Similarly, a mechanismmay be provided to allow a placed module to be removed from a layout.

As shown at 635, user modification of the layout may cause the modifiedlayout to be in an inconsistent state with respect to the relevantdesign rules and properties, or to otherwise have conflicts. Forexample, manual addition of a module by a user at a particular point mayviolate a design rule regarding setback. As such, modifications of alayout, such as addition, replacement, or removal, may causere-calculation of a layout, recalculation of the routing/wiring schemefor a layout, etc. Modifications of the layout, or any inconsistencieswith layout rules, may be noted on an exceptions list as discussed belowin more detail. Some implementations may allow a user to disable anyautomatic re-calculation, and some implementations may allowre-calculation to be invoked by a user.

At 640, user interface controls may be provided so as to allow a user toperform additional actions with or upon a generated layout. For example,a layout may be saved, printed, and/or transmitted. Additionally, layoutinformation, as well as rules and categorizations of objects, may beused to generate additional materials. For example, the performance,e.g., power output, of a particular module layout may be simulated usingencoded information related to features in the representation, e.g., theefficiency of the user-selected model of solar collector and anenergy-predication simulation rule relating to the amount of sunlightreceived by a roof area, such as latitude and/or height. Such results,e.g., simulation results, may be displayed or otherwise made availableto a designer. As another example, the number and cost of modules andassociated components (such as wiring and electrical inverters) may betallied and used to generate a bill of material, cost estimates,invoices, etc. Multiple types of documents or deliverables, such asthose noted in connection with typical layout design processes, may beautomatically generated by some embodiments as a downstream output.

3. USER-DEFINED WORK AREAS

The systems as described thus far have largely provided for layout ofsolar collectors, and particularly PV modules, over allowable surfacesor objects, such as roofs, through the use of implicit work areasdefined by feature classifications. Additionally or alternatively, asystem may provide a user interface to allow more fine-grained controlover the layout process by giving the user explicit control over thedefinition and use of work areas as regions in which modules are allowedto be placed (notwithstanding violations of other design rules).

In particular, as illustrated in FIG. 7A, a system may allow a user todefine one or more user-created boundaries for constraining or expandingmodule layout, e.g., explicit work areas. A work area may represent aboundary, extent, or set of allowable module installation regionscorresponding to locations at the physical installation worksite. A workarea may be coextensive with an object or set of objects correspondingto the physical installation worksite. Alternatively, a work area, suchas that at 701, may cover only a portion of anotherwise-layout-allowable object. A work area may also span overmultiple objects, and multiple work areas may be defined. An explicitwork area 701 may be created by selecting a “work area” toolbar iconwith a pointing device (e.g., mouse, touchpad, joystick or touch screen)or keyboard shortcut and subsequently drawing a rectangle, polyline, orother object. A user may define a work area by any method of defining ageometric object, including dragging a rectangle and clicking a “workarea” toolbar icon or using a context menu. In the illustratedembodiment, objects may be marked (or otherwise associated) by a user asexplicit work areas. A user-created work area may, but need not, becoextensive with any object, e.g., building surface or field, or thevisual representation entirely. User-created work areas may be used inaddition to, or in replacement of, implicit work areas.

In some cases, a layout engine may be configured to place PV modulesonly in the intersection between an implicit work area, such as a roofor field and an explicit work area. In other cases, an explicit workarea may define allowable placement areas without regard to (or inaddition to) other placeable objects or implicit work areas. Explicitwork areas may be used to override default placement rules for objects.This allows a designer to have greater control over where to placemodules, such as whether to place modules on only a portion of a roof.For example, as shown in FIG. 7A, if a designer wished to considerplacing objects only in western section of the roof 201, the designercould create a work area 701. In some cases, in the resulting layout,modules would be placed only in the intersection of the roof 201 and thework area 701. Thus, modules may be placed at location A (as consistentwith other rules, such as those for conduit 203), but not at location B.One such layout is depicted in FIG. 7B.

One algorithm for implementing explicit work areas in the context of alayout engine is as follows: With reference to FIG. 6A, at 620,preferably modules are tiled only in locations that are contained withinboth a placeable object (such as a roof or a field) and an explicit workarea. The method may then proceed as described previously. Analternative algorithm is to tile modules on all allowable surfaces and,at 625, subsequently mark or remove them if they fall partially orcompletely outside the boundaries of all explicit work areas.

Work areas may be modified by the user, such as by moving or otherwiseadjusting a boundary of the work area. Modification of a work area mayor may not cause automatic recalculation or regeneration of a previouslygenerated layout.

4. APERTURES

In addition or alternatively to work areas, a system may provide a userwith the ability to define one or more boundaries for application of oneor more localized sets of design preferences, e.g. layout apertures.Apertures allow a designer to create heterogeneous zones for the desiredlayout and may be used to provide another layer of control to the layoutprocess. A layout engine as previously described may use a single set ofdesign preferences (e.g., module type, orientation, start point, etc.)for laying out modules. Alternatively, a user interface may be providedwith controls to allow a user to define one or more apertures, each ofwhich may include a boundary. Multiple apertures may be associated withindependent and heterogeneous sets of design preferences. Differentapertures may have different extents; layout of PV modules within theboundary of an aperture may typically (with exceptions) be determined atleast in part by the user-defined design preferences associated with theaperture.

As such, and as shown in FIG. 8A, a user may define a first aperture801. The aperture boundary 801 may be coextensive with an object, suchas a roof 201, and/or an explicit or implicit work area; or, as shown inFIG. 8A, the aperture boundary 801 may cover only a part of a placeableobject, such as the roof 201. The aperture boundary 801 may also covermore than one work area and/or object onto which modules may be placed.The first aperture 801 may have a set of design preferences associatedwith it, as shown at 702-705. Aperture design preferences may include PVmodule type or model, module orientation to true north, inter-row andcollector spacing, tilt angle, mounting method, string output voltage,inter-row offset and aperture size and shape, tile starting point, andother properties. (See Table V for additional examples.) In someembodiments, a user may modify some or all of the design preferences ormay continue with the defaults. As mentioned above, a user may alsodefine new module types or models and possibly other enumeratedproperties such as mounting methods while specifying an aperture'sdesign preferences. These newly defined entities are advantageouslyavailable for subsequent use in the same manner as previously definedentities. A second aperture 802 may be created, and may similarly coverall or some portion of a work area and/or placeable object, such as roof201. The second aperture 802 may have a different set of designpreferences associated with it. Apertures may be created by the user, ormay be automatically defined or pre-defined. For example, a generaldefault aperture, covering the entirety of a particular work area or theentire representation of the worksite, may be initially defined as adefault. Alternatively, the software may require a user to define atleast one aperture before operation of the layout engine. An aperturemay be created, for example, by selecting a geometric object andclicking a toolbox icon or using a context menu, as shown at 805.Multiple controls for adjusting aperture rules may be provided; forexample, a user may be allowed to pick a linear reference object to beused as orientation of the module layout in the aperture.

In some cases, the arrangement of modules placed in an intersection oroverlap between an aperture and a work area will depend on theaperture's design preferences. So, for example, with reference to FIG.8A, assume a work area coextensive with the roof 201 has been created(either implicitly or explicitly). When a layout engine is invoked,modules may be placed in location A according to the design preferencesof the first aperture 801; modules may be placed in location B accordingto the design preferences associated with the second aperture 802; itmay be that modules may not be placed in location C because C is notwithin an aperture (or they may be placed and marked as illegal). Insome cases, apertures may overlap, as at location D, which means thattwo or more sets of aperture design preferences may apply to location D.In these situations, some systems will apply aperture conflictresolution rules, described in more detail further below in connectionwith FIG. 9. Modules may not be placed in Location E because Location Eis not within a work area. FIG. 8B depicts an illustrative layoutaccording to the foregoing, wherein the layout conflict in region D hasbeen resolved in favor of the first aperture 801. Aperture conflictresolution rules are discussed in further detail below.

Apertures may be useful, for example, because they may allow a designerto specify one set of design preferences and properties for a firstportion of a work area or object, such as a roof, and a second set ofdesign preferences and properties for a second portion of the same workarea or object, as shown in FIGS. 8A and 8B. So, for example, if solarcollectors are to be placed on two sections of the same rooftop, but onesection is flat while the other is sloped, a designer may choose twodifferent mounting angles to the vertical, orientations relative tosouth, PV module models, and/or mounting systems appropriate to the tworoof types. Similarly, if one side of a roof is particularly windyrelative to another side, a user may create a first aperture for thewindy side, using design preferences that include wind-tolerant modulesand mounting systems, and a second aperture, using less-tolerant modulesand mounting systems, for the less-windy portion of the roof. Aperturesmay also be moved or adjusted by a user (as with a user-defined workarea), and this is one way such a system may provide the ability for adesigner to quickly visualize alternative layouts.

Because apertures may provide differing sets of design preferences formodule placement, overlapping or adjacent apertures may cause conflictsin placement. This overlap may be substantial. Aperture conflictresolution rules may be used to resolve inconsistencies in moduleplacement. One simple form of conflict resolution rule is to rankapertures in creation-order, with either first- or last-created aperturehaving highest priority. Lexicographic order may also be used. A usermay be provided with a control to explicitly change the aperturepriority order. One method of doing this is to associate each aperturewith a user-editable design preference defining its priority, e.g.,“priority=2.” A default aperture, if any, may have the lowest priority.

Numerous methods may be used to create modules layouts in accordancewith the aperture conflict resolution rules. As an example, aperturesmay be given a priority as described above, and, in the case of aconflict in placement, priority is given to placement according to thehigher-priority aperture.

For example, independent, partial layouts may be generated for alldefined apertures, regardless of priority, according to the methodsdescribed above as applied primarily to objects and features falling atleast partially within each aperture boundary. This computation may beperformed in parallel. If no apertures overlap, the union of the twopartial layouts may be taken as the ‘final’ layout and may be saved,stored, or rendered on an output device. If there is overlap, however,the conflicts between placed modules may be reconciled based on conflictresolution rules. In some cases, of the conflicting modules, those fromthe lower-priority aperture may be removed, thus modifying or adjustingthe partial installation layout corresponding to the lower-priorityaperture. As shown in FIG. 9A, one method of laying out involves, uponstarting 900 the process, first inputting worksite data (e.g., physicaldimensions of boundaries and structures) at 901; classifying objects andcreating work area(s) and aperture(s) at 902; creating layouts ofmodules in each aperture at 904; analyzing each module in each aperturefor conflicting placement with respect to other modules and/or otherapertures at 906; using aperture priority rules to resolve any conflictsat 908, and allowing the user to modify module placement made accordingto the foregoing at 910. The process ends at 912, although it will beunderstood that numerous additional intervening processes and repetitionof similar steps to the above can be conducted.

Another method of accomplishing this is to analyze each aperture inorder of priority, from highest to lowest, and place modules as possible(according to the above) in that aperture, provided such placement isnot inconsistent with modules that have already been placed as part ofhigher-priority apertures. Placement of PV modules will typically takeplace within the boundaries of a given aperture according to the designpreferences of that aperture as applied to the features that intersect(or contain or are contained) within that aperture (as well as thosethat are outside that aperture but have, for example, setback rules),feature properties, module properties, and project properties. Thismethod produces a set of successive installation layouts, where eachsuccessive layout is consistent with the design preferences of thepresent and all higher-priority apertures. Each of the successiveinstallation layouts may be rendered or stored on a device or medium.

FIG. 9B illustrates another example process for laying out modules inaccordance with classified objects, work areas, and conflictingapertures. After the start 930 of the process, at 931 a user may firstclassify objects and create one or more work areas and/or apertures (ordefault or implicit work areas and apertures may be used). In someembodiments, apertures may be associated with a relative sequence ofcreation that may determine their priority in subsequent conflictresolution.

At 932, modules may be placed according to the rules of the firstaperture, where “first” may be determined by relative priority rulesdescribed above. Modules may be placed only within the boundaries of thefirst aperture and a work area, whether implicit or explicit. Ifexplicit work areas are defined, modules may be placed only in theintersection(s) between an aperture, a placeable surface, and anexplicit work area. If explicit work areas are not defined or not used,modules may be placed in the intersection of an aperture and a work areadefined by a placeable object, such as a roof. At 933, modules thatconflict with one or more design rules, such as violating setbackrequirements for exhaust fans, are marked illegal, and thereafterremoved or otherwise taken out of the active layout.

At 934, the steps 932 and 933 may be repeated for asecond-highest-priority aperture (if any). However, in some cases, inaddition to the usual requirements of intersection with a work area,modules may only be placed in the second aperture if they do notconflict with modules already placed in the first aperture. This may beaccomplished in the equivalent to the placement stage (932), e.g., neverplacing modules that conflict with the first aperture. Alternatively,modules may be placed across the second aperture without regard to thefirst aperture's modules or design preferences, and subsequently removed(during the equivalent of step 933) if found to be conflicting with themodules placed in the first aperture (or the design preferencespertaining thereto).

At 935, steps 932 and 933 may be repeated for a third-highest-priorityaperture (if any). Modules may be placed in the third aperture, andaccording to the rules of the third aperture, but only if they do notconflict with modules placed in the first or second apertures or designpreferences thereof. This process can be repeated optionally, as shownat 936, for all remaining apertures in turn. At 937, or at an earliertime, a user may be allowed to modify module placement, which may leadto regeneration of all or part of a layout, based upon the stepsdescribed above. As noted above, additional intervening steps may betaken, and any of the above steps repeated as desired before the processends at 938. The final layout may be displayed on a computing device orotherwise rendered or stored.

5. PROJECT HIERARCHY AND STORAGE

A solar installation project design, including a representation of aproject worksite, features and their classifications, and a layout ofsolar collectors, may be characterized by project state information.Project state information includes, generally speaking, the informationthat can be used to re-create, without more, a particular solarcollector installation design. So, for example a typical use of projectstate information is to allow a design to be saved in a non-volatilememory. Invoking a “save” function or control on a particular design maycause project state information to be written to a hard disk. Thesoftware program may then be terminated (clearing all of its workingmemory) and restarted. A user may then select an “open” function orcontrol and point the software to the saved project state information.The software may then load and operate upon the project stateinformation to re-create the solar installation project.

In some cases, the entire contents of the software's working memory whendisplaying a particular design can be recognized as “project stateinformation,” since such is enough to fully specify a particular design.However, one advantage of using project state information is that onemay use only a subset of the working memory (or even other data), thusreducing both the size and the complexity of the project stateinformation. For example, a given design may include a layout of onemillion collectors, all of which are of the T10 module type, and laidout in a 1000×1000 sub-array. One way of storing such a design is, e.g.,to allocate and store one million “collector” data structures, each withtheir own copies of relevant properties (such as “Module Type=T10,”location, orientation, etc.) Alternatively, a system might simply storestate information along the lines of “1000×1000 sub-array of T10modules, oriented 0 degrees.” This more compact representation ofproject state information may be more convenient to store and easier tomodify. For example, if a designer were to change the module type forall the modules from T10 to something else, performing that change maycall for a scan and change to one million data structures under thefirst example. Under the second, however, only a single change to thestate information may accomplish the modification.

In some embodiments, project state information for a given design willinclude all of the design inputs, e.g., the data used to regenerate thedesign. So, for example, project state information may include inputinformation such as the representation of a worksite including geometricobjects, classifications of these geometric objects as features, featureproperties for each of the classified objects, design preferences, workarea definitions, aperture definitions and attendant design preferences,project properties, etc. Project state information may also includeother types of inputs, such as user modifications to generated layoutinformation. For example, when a user manually adds a module to agenerated layout, such as when the user changes the status of aparticular module from “illegal” to “legal,” that module's status may bereflected in project state information.

Project state information may also include output information, such asgenerated layouts, performance and cost characteristics of same, etc.For example, a bill of materials for a particular design is an output ofthe design, since it is a function of the inputs of the design, e.g.,design preferences. This may allow, for example, caching of outputinformation to reduce computational demands.

Efficient management of project state information can be difficult. Inparticular, in some embodiments, project state information may providefor “conflicting” information, such as when a user places a PowerGuardmodule within an aperture boundary designated as T10. If the system isto give effect to both of these actions by the user, it may be useful tohave an efficient and powerful representation of project stateinformation.

Accordingly, in some embodiments, the project state information may berecognized as an arrangement of hierarchical elements, which may berepresented in a data structure. In some situations, the hierarchy mayapproach a tree-like structure, in which sub-elements are assigned aunique parent object. In other cases, the hierarchy may be an instanceof a more general graph, such as when a particular object has more thanone parent object in the hierarchy.

FIGS. 10A-B provide an illustration of a project state informationhierarchy that may be used by a solar collector layout design tool. Inparticular, as shown in FIG. 10A, an overall project 1000 may contain aworksite representation 1001, which may include one or more features1002. Each of the features 1002 themselves may contain featureproperties.

A worksite representation may also include work areas 1005, such as thetwo work areas illustrated in FIG. 10A. Each work area 1005 may containone or more apertures 1010; e.g., the first work area 1005 may containtwo apertures at 1010. This may be the case if, in a worksiterepresentation, an aperture 1010 falls within the boundaries of a givenwork area 1005. In the case of a single aperture that overlaps multiplework areas, the aperture object 1010 may be shared between or duplicatedamong the work areas. Alternatively, the hierarchy may be adjusted touse work area-aperture intersections (rather than entire apertures) asthe child object for work areas 1005.

As discussed above, according to some embodiments, solar collectors willbe placed in the intersections between aperture 1010 and work area 1005.As such, each aperture or work area-aperture intersection may includeone or more sub-arrays 1015 of collectors within the apertures 1010. Thenumber and composition of sub-arrays 1015 in a given aperture 1010 maybe a function of multiple variables, including obstruction featureslocated within or around (in the proximity of) the boundaries of theapertures. For example, a linear obstruction (such as a wall) thatbisects an aperture may cause the layout of collectors within theaperture 1010 to be divided between two sub-arrays 1015, one on eachside of the wall. Some embodiments may cause sub-arrays 1015 to haverectangular shapes, other embodiments may create a sub-array 1015 out ofeach contiguous group of collectors in an aperture 1010, regardless ofshape. Still other embodiments may utilize other rules 1004, such aswiring or output requirements, to form sub-arrays 1015.

A given sub-array 1015 may be further divided into strings 1020 ofcollectors 1025. In some situations, as may be the case with PV modulesand as discussed above, depending on the selected model, a given numberof collectors may need to be wired together in a particular fashion,e.g., in series, in order to produce a required output voltage. So, forexample, if the required output voltage of a given sub-array is 150V atpeak power, and if the particular modules being used to form thesub-array each put out 15V at peak, then the modules may be grouped intostrings of 10 modules each for installation. The collectors of eachstring may be wired in series, and each string of a sub-array may bewired in parallel to the other strings of the sub-array. Accordingly, agiven sub-array 1010 may be composed of multiple strings 1020. Each ofthese strings 1020 may be composed of collectors 1025.

As shown in FIG. 10B, a given solar collector may be itself be composedof a hierarchy of elements. For example, a PV module may be composed ofcell strings 1030, each of which includes a series of cells 1035 (justas an sub-array 1015 may be composed of strings 1020 of modules 1025 asshown in FIG. 10A). For example, a 15V module may be composed of threecell strings wired in parallel, where each cell string contains ten 1.5Vcells wired in series.

Each of the elements at each level of the hierarchy may be associatedwith a set of properties. For example, the properties of a given stringmay include module count, string location, etc. Some of the possibleproperties that may be associated with particular work areas, apertures,projects, and features have been illustrated above. The properties of anelement may be represented absolutely or with reference to another setof properties. For example, default values for properties may beinherited from parent elements in a data structure representing thehierarchy, and those default values may be overridden by values forproperties stored with a given child.

Like properties, design rules such as feature layout rules employed bythe layout engine may be associated with the respective elements in thehierarchy. Design rules that are not specific to particular instances offeatures may be associated with the project or worksite generally, asshown in FIG. 10A at 1004. Design rules may also be inherent to aparticular layout or design engine or otherwise not represented in theproject state information hierarchy. Similarly, design preferences mayalso be associated with respective elements in the hierarchy: Projectdesign preferences may be associated with a project element. Thehierarchical data structure also provides flexibility in thecategorization of properties, design preference, and rules: E.g.,collectors placed or modified by a user may be classified as features1002 with attendant properties, may be maintained at a separate level ofthe hierarchy (as shown at 1025) or both.

In some embodiments, the data structure used by the software torepresent project state information, for example, to use for storing andretrieving projects, may be represented as a hierarchical relationshipamong a collection of elements, the properties, and the design rulesassociated therewith. For example, project state information may berepresented in an XML-type format, wherein a top-level worksite node maycontain a listing of features and their classifications. The worksitenode may also contain a number of work area nodes, which may, in turn,contain a number of aperture nodes. Each aperture mode may containsub-array nodes, and so forth. A project hierarchy data structure mayrepresent the state of a design project, in the sense that sufficientinformation to regenerate a layout may be contained within the datastructure.

6. PROJECT EXCEPTIONS

In some embodiments, as a designer goes through the process ofclassifying features, generating layouts, and then modifying thoselayouts, as discussed above, metadata about the design process may begenerated. Metadata may be determined from the rules that are applied toproject state information, such as feature properties, designpreferences, version information, etc. This metadata may take manyforms, and may include information about actions the designer has taken,actions the designer should take, and design information that may beuseful to supervisors, co-designers, and downstream users and recipientsof the design. The metadata, and other data, may be used by a system togenerate a list of “exceptions” that may encode one or more exceptionalconditions in the metadata, e.g., a violation of a rule by the projectstate information per se, the project state information as reflected ina design output, or some other condition. Exceptional conditions, andcorresponding exceptions, may be related to omissions by the user,violations of regulations, violations of solar collector manufacturerspecifications, violations of client requirements, violations ofengineering principles, violations of physical space constraints,violations of company engineering policy, etc.

Such a list may allow a designer to have more flexibility in thesequence of actions to perform when generating an installation designwhile still ensuring that the proper actions will be performedeventually and that exceptional conditions, such as design flaws, arenot overlooked. In particular, rather than being forced to performworkflow in a certain order, an exceptions list may allow a designer toperform actions in an order of his or her choosing. The exceptions listmay be presented to a user without requiring the user to address any ofthe exceptions (or exceptional conditions) before performing anotheraction. An exceptions list may also provide the ability for a designerto decide whether (or not) to address a particular exception Anexceptions list may also provide a simple interface to importantinformation about a design, such as questionable module placement, etc.Thus, a user is allowed to effectively ignore (at least temporarily) anexception, to be dealt with at the user's schedule as part of a “To Do”list. An embodiment may provide an option to a user to ignore a givenexception by, for example, making the exception or exception listnon-blocking in the user interface. The user is also given the optionsto comply with the software's expectations for the exceptionalcondition, such as by providing missing information or removing illegalmodules from a generated or user-modified layout. Metadata andexceptions may also be useful for maintaining and generating downstreamdocuments, such as contract exclusions.

In some embodiments, some or all of this metadata, including exceptions,may be associated with the design, such as by common storage orreference with the data structure hierarchy discussed above. Thereafter,downstream users and processors of the design, including automatedsystems, may use the metadata. The metadata may also be summarized,exported, translated, or otherwise operated upon by the system.Metadata, and exceptions generated therefrom, may include, among otherthings, information about contractual exclusions, warnings to thedesigner, and errors in the worksite representation or layout.

As illustrated in FIG. 11, a user interface 1100 may be provided suchthat some or all of the metadata about the design may be presented tothe designer in the form of a list 1105 of exceptions. Therepresentation may include a layout, a list of design exceptions, andcontrols operable to interact with the exceptions. An exception mayindicate that some action on the part of the designer is called for. Insome cases and for some exceptions, although an exception may begenerated, the designer might not be impeded in the design process forfailure to supply the requested information. For example, in someembodiments, the location of the worksite, perhaps as approximated byzip code, is a worksite property that impacts layout. This may be thecase where different zip codes imply different regulatory regimes, e.g.,different requirements for rooftop loading, setbacks, and so forth.Accordingly, the design rules may request the supply of a zip code. Insuch a case, if a designer has failed to specify a zip code for theworksite, that failure may be noted as metadata about the design and azip code exception 1110 may be generated. During the pendency of the zipcode exception 1110, the designer may still be allowed to classifyobjects and generate a layout or downstream documents, perhaps using adefault zip code or regulatory regime supplied by the system

Alternatively, the system may allow the designer to perform somenon-related actions while an exception exists, but may require that thedesigner address the exception before a particular action, such aslayout generation, simulation, or downstream document generation isallowed. For example, the designer may be allowed to continueclassifying objects before entering a zip code, but may be precludedfrom generating a layout. As another example, other metadata mayindicate fatal conditions, in that continuation with the design is notan option. For example, if a designer places a module over an exhaustfan, the system may generate an error exception 1115. The designer mayaddress the exception 1115 before a finalized design may be created. Ifthe user has not addressed an exception (i.e., ignored it), it mayremain in the exceptions list 1105 for supervisor review. Some types ofaddressing by the user, e.g., compliance with the requested or change,can remove the item from the exceptions list. Other types of addressingby the user, e.g., overriding or otherwise explicit refusal to complywith the requested information or change, results in modification of theexception and maintenance of the exception and the user override inputin an exceptions history, which will be useful for future modification,supervisor review, contract generations, etc. Other types of exceptionsare discussed below.

A designer may interact with exceptions that call for designer action ina variety of ways. For example, the designer may choose to address thezip code exception 1110 by entering a zip code for the worksite. Thismay be done in several ways, including through the mechanisms describedabove for entering project properties. Alternatively, the exception 1110itself may be associated with a mechanism for addressing it. Forexample, a zip code exception 1110 may include a field into which a zipcode may be entered and thereby associated with the project. When theuser addresses an exception, it may cause the system to recalculate orregenerate information. For example, when the user enters a value intothe zip code exception, the system may validate the zip code and may,for example, regenerate a layout with the new location information. Inresponse to an exception, a user may provide compliance informationsufficient to remedy the exceptional condition or rule violation, whichinformation may include, for example, a project property, a customerproperty, a feature property, a design preference, a work area boundary,or an aperture boundary. Some embodiments may recognize the complianceinformation and use the information to modify project sate informationor other design information. After receiving the compliance information,the system may remove the corresponding exception

A system may include also exceptions that reflect information ormetadata about a design that may be useful for downstream users andprocesses. For example, if a designer places a module in a configurationthat overlaps with a feature classified as an “illegal wind zone” (asmay have been determined by an on-site inspector), an exclusionexception 1120 may be generated. These exclusion exceptions may bepresented to the designer, as discussed above, and the designer mayoperate upon a control to comply with, e.g., remove or ameliorate, theexception (by, for example, removing the particular module in question).Alternatively or additionally, some exceptions, including some exclusionexceptions, may be maintained with or associated with the design and,thereby, made available to subsequent processes that use the design. Forexample, another software program may use the exclusion exceptioninformation to generate a list of contractual exceptions that may belisted as part of the terms of a contract between a designer and aclient. So, for example, the exception 1120 corresponding to the moduleplaced in the leaky roof region may be used by a downstream process togenerate a specific term for a contract that limits the designer'swarranty for the module placed in the leaky roof region or disclaimsliability for certain ensuing damage. Exceptions may also trigger theinclusion of terms relating to price, as exemplified by an exceptionthat may be raised when the total cost of the project exceeds thebudgeted cost and a term to that effect is added to the contract.Exceptions may also trigger the inclusion of terms relating to the scopeof work, as when modules are laid out on or in proximity to anobstruction and the response to the exception is to indicate that thecustomer is responsible for removing or modifying the source of theobstruction so as to make the design acceptable.

Some exceptions may also be designed to require review and additionalauthorization from a person or authority other than the designer. Forexample, an exception 1125 related to having a roof loaded to 95% of itsmaximum designed weight capacity may require approval of a designer'ssupervisor. The exception may require approval by the supervisor orother second user before the designer may continue, at least withrespect to certain designated actions. Alternatively, the system mayproduce a listing corresponding to all such approval-entailingexceptions, and such a listing may be used as part of the downstreamprocess for the design, thus allowing the user to proceed with at leastsome tasks despite the exception. Later compliance, overriding, orauthorization of overriding of the exception (e.g., by a supervisor) mayregenerate an associated solar collector layout, such that theintervening work by the user is not wasted.

Some embodiments may implement some or all of a combination of the aboveexceptions and actions. For example, depending on the exception,legitimate actions made available to the designer by the system mayinclude variations on “ignore exception,” “automatically fix layout,”“override exception,” “delete collector(s),” “regenerate layout,” “entervalue and recalculate,” “flag for supervisor,” “comply with exception,”and so forth. For example, a user may issue a command, as by softwarecontrol, for a system to takes steps to automatically attempt to rectifyan exceptional condition, as by modifying project state information or adesign in accordance with removing the exception condition.

Some embodiments may make a record of user actions, including thosetaken as part of addressing an exception, including user authorizations.Records of actions may be associated with exceptions, stored with agiven project, exported to a downstream user, and so forth. Otherembodiments may be configured to re-evaluate the presence of exceptionalconditions, with or without user input or impetus; as such, if anexceptional condition is no longer present, the system may remove theexception.

FIG. 12 illustrates a process for implementing exceptions. At 1205-10,the system may enter an input-validation loop. At 1205, a designer mayinput worksite information, classify objects as features, and enterfeature properties and other design properties and preferences. At 1210,the system may analyze and validate the designer's input, as by applyingrules to the geometric objects and other input information in theproject state information. A validation engine may use validation rulesthat are specific to the type of project or may be generalized. Suchvalidation rules may be stored with the project hierarchy or may beexternal to the project. As any variances are noted by the validationengine, they may be placed in a list of exceptions, e.g., in a datastructure in computer memory, at 1212. These exceptions may be displayedto the user as described above. The user may choose to addressexceptions that have been placed on the exceptions list; alternatively,the user may input more properties, classifications, and otherinformation.

The input-validation loop 1205-10 may continue until the user causes alayout to be generated, as at 1215. This may cause the system to enter alayout-validate-modify loop 1215-20-25-30. As shown at 1220, theresulting layout may be analyzed and validated for conformance to thedesign preferences, feature and project properties, layout rules,desired outputs, and other encoded information criteria. Any variationsor deviations arising from the generated layout may again be noted asexceptions and placed on an exceptions list, at 1222. At 1225, the usermay be presented with the ability to modify the layout as discussedabove. This may include changing properties or preferences, addressingexceptions (which may cause a change in properties or in the layout),adding or deleting modules, and so forth.

As shown at 1230, the user's actions may be validated by the validationengine. At 1232, exceptions caused by the user's actions may again beadded to a list of exceptions. In some cases, changes made by the usermay trigger regeneration of the layout. For example, if the userincreases a setback property, the layout may be regenerated to beconsistent with that increased setback. Depending on the type ofexception, the 1225-30 loop (where user entries are validated andexceptions generated without a regeneration of a layout) or the1215-20-25-30 loop (where user entries cause a regeneration of thelayout) may be repeated as necessary or desired by the designer.

At 1235, some or all of the metadata generated through this process,including exceptions and the actions taken to address them, if any, maybe stored or otherwise made available for downstream users. For example,a list of contract terms may be generated from all of the contractexclusion exceptions and a list of all of the approval-requiredexceptions may be generated and forwarded to the appropriate approvalentity. A user interface may provide a list of contract exceptionscorresponding to exceptional conditions related to violation of a designrule by the solar collector installation design, where the contractexceptions or conditions provide information sufficient to identify aterm for inclusion in a contract. In general, any metadata, exception,or action by the user may be included as part of the project stateinformation.

7. PROJECT VERSIONS

Some embodiments may provide a system and user interface for viewing,creating, and manipulating multiple versions of a solar collector layoutdesign for a particular installation worksite. The use of versions mayallow, for example, a designer to view layouts and other outputs fromselecting alternative modules, alternative feature classifications,alternative work area and/or aperture boundaries, and other types ofalternative inputs or design preferences quickly and easily. Theseversions provide the designer with the ability to view output changesfrom various input changes interactively. Some embodiments may allow thedesigner to quickly move from one version to another, while others mayallow a designer to affect multiple versions with one action. A givenversion may include user-defined project state information that providesa unique set of user-defined design preferences, feature properties, andproject properties. Different versions with different sets of this inputinformation may correspond to alternative solar collector installationlayouts, where the alternative layout for each version results fromdifferences between the unique sets of data. The unique sets of data mayalso include work area state information, aperture state information,geometric object information, etc.

In some embodiments, different versions of a given installation projectwill share worksite and/or feature information, including properties.Such versions may define possibly-differing work areas, apertures, andlayouts. In other embodiments, versions might not share all featureinformation and, therefore, differing versions may have differentfeatures, classifications, or feature properties. Versions may shareinput project state information of various types, including geometricobjects, object classifications, and feature properties, projectproperties, among others. Versions may share data by maintainingcoherency between separate data sets. This may be accomplished by havingmultiple versions reference the same copy of shared project stateinformation, as by referencing the same location in memory, as by apointer. Each type of input data, such as design preferences, featureproperties, project properties, etc., may be bifurcated, where one ormore of the individual data are shared and/or one or more are notshared.

Related versions may share information at one or more levels of thehierarchy described above in connection with FIGS. 10A-B. For example, aset of related versions may share a common description of a worksite,its physical characteristics, including features, and classifications offeatures. Versions may branch off from each other at any point in thehierarchy. In the case of a tree-like hierarchy, elements above thebranch point may be shared among the versions, such that changes to anabove-branch datum may be applicable to both versions. Alternatively,two or more copies of below-branch data may be maintained, one for eachversion, such that change to a below-branch datum in one version may notimpact the corresponding datum in the other version (if any).

In some embodiments the branch point among versions may be at the workarea level. For example, FIG. 13 illustrates three versions at 1305. Theversions 1305 are illustrated as depending from, and thereby sharing, aworksite and, thus, the versions may share several sets of encodedinformation, including design rules 1004, some or all features 1002 andtheir classifications and properties, etc. In such a situation, a singlechange made to the worksite 1001 or features 1002, such as are-classification of a geometric object to another type of feature, achange in a feature property, etc., will be applicable to, inherentlypart of, and thereby reflected in, all three versions 1305. In anotherexample, each version 1305 may contain distinct and independent workareas 1005, apertures 1010, and related sub-elements generated by thelayout engine (such as sub-arrays, etc., which are not shown). In thiscase, changes made to a work area, aperture, or sub-element (such as amanual placement of a particular module, or a change in the wiringpattern of a string), may be applicable only to the version in which thechange is made. This may be useful because a designer may wish theproject description, such as feature classifications, to be invariantacross all versions. Rather than forcing a designer to manually updatemultiple versions manually with a single change in a feature property, asystem that provides shared classifications among versions is arrangedto “automatically” update all related versions.

In this way, a project data structure may include alternative versionsof the design, where each alternative version includes independent(non-shared) project state information and shared project stateinformation as described above. The (non-shared) independent projectstate information differs for each version. As such, when taken incombination with shared project state information, the state informationmay define an installation design that differs among the differingversions.

Some embodiments may allow branching between versions at higher or lowerlevels of a hierarchy. For instance, versions may branch at the highestlevel of the hierarchy, whereby versions do not share any commonfeatures, including feature classifications. Alternatively, versions maybranch at a low level, e.g., at the string level for a particularsub-array, e.g., if one version has modules grouped in strings innorth-south rows, while the alternative version has modules groupedprimarily into east-west rows. In such a case, the two versions mayshare elements above the branch points (such as general aperture designpreferences), such that a change in the aperture settings of one versionwill affect the other version.

As shown in FIG. 14, systems in accordance with some embodiments mayprovide a user interface for viewing, creating, modifying, and operatingwith different versions. In particular, a listing 1400 of one or moreversions may be provided. The listing 1400 may reflect one or morelevels of hierarchy particular to a given version, as illustrated herewith respect to “Version 1.” The interface may provide a mechanism, suchas a toolbox control 1450, whereby a version may be activated (orselected) for display or other operation in the user interface. Iflevels of hierarchy are displayed, as shown for Version 1 at 1405, acontrol may be provided to allow a user to select a sub-element, such asthe first aperture 1410 of Version 1 1405 and thereby to cause anoperation upon that sub-element, such as highlighting in the visualrepresentation, display of a properties box (not shown), summaryinformation and so forth. The listing 1400 may reflect or illustrate thebranch points of various versions.

When a version is activated, the contents of the version may bedisplayed in a visual representation. For example, when a version isactivated, the aperture, work area, features properties, module layout,exceptions, and so forth corresponding to that version may be displayed.Activation of a version may cause the layout engine to recalculate thelayout corresponding to the version (consistent with the version'sproperties). Activation may also cause information about the version,such as summary information, to be displayed, such as in a status lineor field. As worksite features are created and classified, and aslayouts, exceptions, and so forth are generated, those properties andexceptions may be associated with the presently activated version.

When a change is made to the activated version, if that change is madeto an element that is shared with other versions, that change may bereflected in the other versions as well. So, for example, if twoversions share feature classification information as described above,then re-classification of a given feature of the worksite ormodification of its properties may impact both versions. A change thatis reflected in a non-activated version may cause recalculation of alayout associated with that version. For information that is not sharedbetween versions, changes made to an activated version may not affectother versions.

A mechanism, such as a new version toolbox control 1455, may be providedwhereby a new version may be created. A new version may be created fromscratch (and subsequently filled with worksite properties). This may thecase when an initial version is created by default as the first (and, atthat point, only) version of a new project. Alternatively oradditionally, a new version may inherit some solar installation projectproperties, such as project properties and feature classifications (ifany exist) from a previous version. So, for example, if a set offeatures have been defined and classified, a newly-created version mayinherit these features and classifications

A mechanism, such as a version-copy toolbox control 1460, may also beprovided whereby a version may be copied or duplicated. A new versionmay be created by being copied (e.g., branched off or duplicated) from apre-existing layout or version. The currently-activated version may beused as the version from which the new version will be branched off. Thenew-copied version may start with all or most of the properties of itssibling version, e.g. same worksite properties, apertures and apertureproperties, exceptions, and so forth, as when the duplicate version isinitially populated with at least some of the same state information asthe original version. Subsequent modifications to the newly-copiedversion may or may not be reflected in the original version, depending(as shown in FIG. 13) on whether the changes are to elements shared bythe versions. In some embodiments, the user may make changes to theunique set of user-defined design preferences and feature propertiescorresponding to a new or duplicated version that are not reflected inthe unique set of user-defined design preferences and feature propertiescorresponding to any version created before the new or duplicatedversion.

A mechanism, such as a version-delete toolbox control 1465, may beprovided whereby a version may be deleted, e.g., removed from thedisplay and, potentially, removed from storage associated with theversion. A similar mechanism, e.g., version-rename toolbox control 1470,may be provided to rename versions.

Mechanisms may be provided to generate information particular to aversion, or otherwise operate upon a version, such as parts-summarytoolbox control 1475 to generate a parts summary (as in a .CSV file) ofa version; a version-export toolbox control 1479 to save versioninformation to another format, such as a database record or set ofrecords; a version-simulate toolbox control 1485 to perform and/orgenerate simulation data regarding a version; aversion-simulation-export toolbox control 1490 to store or exportversion simulation information, such as in a .CSV file; and so forth.Each of the foregoing may be applied to a currently activated version, aselected version or set of versions, or to all versions.

A control 1477 may also be used to generate a summary of the variousversions of a project. This version summary may include a variety oftypes of comparative information about each of the versions, includinglayout information, such as solar collector count, cost, weight, etc.;simulation data, such as expected performance, peak power, cost perkilowatt-hr generated, minimum energy productions, etc.; and other typesof information, such as exception count and types, etc. Informationabout illegal and deficient or otherwise poorly-placed modules in aversion may be noted in a version summary. Version summary informationmay also be generated about information for each version such asprojected performance, simulation information, electrical power, powerefficiency, cost, materials, physical size, part count, and exceptions.This information may also be generated and displayed for sub-elements ofa particular version, such as work area, apertures, sub-array, modules,strings, and so forth. FIG. 15 illustrates a sample version summary 1500in which several versions 1510 have been summarized. A designer may useversion summary information for many purposes, including to select amongvarious versions and/or to identify errors or inefficiencies inversions. Version summary information may be exported to an externalfile or storage. A user may select which types of version summaryinformation to display or export.

The various versions of an installation project may be stored inmultiple files, or advantageously, in a single file. As with thesingle-version installation projects discussed above, a project withmultiple versions may be represented in an XML-type format, wherein atop-level worksite node may contain a listing of features and theirclassifications. The worksite node may also contain a number of versionnodes, which may, in turn, contain a number of work area and aperturenodes. Each aperture mode may contain sub-array nodes, and so forth.Data associated with a version, such as version summary information,name, and so forth, may be stored with the version. In particular,design output information that may vary from version to version, such assolar collector layout information, version summary information,simulation data, contract information, bill of material information,exception information, etc., may be cached or stored or co-located witha version.

In some embodiments, an “undo” control, such as toolbar icon or keyboardshortcut, may be provided to allow a designer to undo one or morechanges to a project and/or to a version. In some embodiments, when adesigner makes a change to a version, whether it be a modification of alayout, a classification of an object, etc., that change may be recordedby the embodiment. A control may then allow the user to “undo” thechange by reversing its effect. In some embodiments, the change may berecorded by taking a snapshot of the state of the project or version.The embodiment may undo the change by reverting back to the snapshot.Alternatively, an embodiment may record the state transition embodied bya change (or its inverse). Performing an “undo” may then be accomplishedby reversing the state transition. In this way, multiple levels of undomay be maintained, as by the use of a snapshot or transition stack.Similarly, a redo function may be implemented, wherein an “undo” actioncauses a snapshot or transition for the inverse (“redo”) action, such asby pushing the inverse of the “undo” onto a redo stack.

8. ILLUSTRATIVE EXAMPLES

FIGS. 16A-E illustrate examples of screen shots from layout software inaccordance with embodiment of some of the systems and methods describedherein. FIG. 16A illustrates a user interface 1600 in which a visualrepresentation 1601 of a worksite with geometric objects correspondingto two sloped roof surfaces meeting at a roof ridge 1602 contains anumber of solid obstructions (vents 1603) and linear obstructions (pipes1604). The user interface 1600 also includes toolbars 1605 and aproperties palette 1606. The interface may include a version display(not shown), a version summary (1620), an exceptions list (not shown),fields 1630 for user input and system output, and may display theforegoing simultaneously.

As illustrated in FIG. 16B, controls in the form of a toolbar 1605 mayprovide a user with the ability to classify objects as features (hereillustrated as a roof control 1610, solid obstruction control 1612, andlinear obstruction control 1613) and to create work area boundaries 1611in the visual representation, the work areas defining an extent intowhich solar modules may be placed. A control to declassify 1614 anobject may be provided. A control to create layout apertures 1615 may beprovided, along with a control to generate 1616 an actual layout. Adisplay control 1625 may be provided to select which interface elementsto display, such as an exceptions list, properties palate, versionsummary, version list, etc. The layout may be substantially limited tothe intersection of the work areas' boundaries and the apertures'boundaries and the layout may be generated at least in part according tothe sets of design preferences associated with the apertures. As shown,helpful (but non-limiting) text may be provided with controls in theform of popups, rollovers, etc. As shown in FIG. 16C, a menu containingcontrols to accomplish many of the same functions may also be provided.As illustrated in FIG. 16D, a properties palette may allow a user to seeand/or adjust the properties relating to a particular feature.

FIG. 16E illustrates the result of generating a layout for PV modules ona visual representation containing two roof objects 1602, two work areaboundaries largely co-extensive with each roof surface, and threeaperture boundaries (two of which are rectangular-shaped apertures 1650extending over only a portion of one roof and one work area, and one ofwhich is an irregular-shaped aperture 1650A extending over a portion oftwo roofs and work areas). As shown, each aperture has a set of modulesplaced within, consistent with the layout rules regarding the respectiveroof, work area, and obstructions contained within.

9. CONCLUSION

Those of skill in the art will recognize that the foregoing descriptionsof categorization and rules are merely indicative of some methods ofpracticing the inventions as defined by the appended claims. Othermethods of laying out PV modules within and around geometric objectsbased on layout requirements associated with a worksite may be used toaccomplish similar ends, such as tables, scripts, data structures, etc.Rules may be explicit and/or comprise declarative statements, asdescribed above or as used in a rule-centric language, such as LISP;alternatively, one or more “rules” may be expressed implicitly in datastructures, imperative statements, program flow, program constructs,placement and arrangement algorithms, etc. Rules are used herein as oneway of illustrating the general method by which a tool may useinformation associated with arbitrary objects to create a PV modulelayout. A particular rule, such as a layout constraint, may beexplicitly associated with a particular object or feature and/or aparticular type or class of feature; such a rule may be defined as partof a layout engine and implicitly linked to objects or classes.

The systems, methods, and techniques described here may be implementedin computer hardware, firmware, software, or in combinations of them. Asystem embodying these techniques may include appropriate input andoutput components, a computer processor, and a computer program producttangibly embodied in a machine-readable storage component or medium forexecution by a programmable processor. A process embodying thesetechniques may be performed by a programmable processor executing aprogram of instructions to perform desired functions by operating oninput data and generating appropriate output. The techniques mayadvantageously be implemented in one or more computer programs that areexecutable on a programmable system including at least one programmableprocessor coupled to receive data and instructions from, and to transmitdata and instructions to, a data storage system, at least one inputcomponent, and at least one output component. Each computer program maybe implemented in a high-level procedural or object-oriented programminglanguage, or in assembly or machine language if desired; and in anycase, the language may be a compiled or interpreted language. Suitableprocessors include, by way of example, both general and special purposemicroprocessors. Generally, a processor will receive instructions anddata from a read-only memory and/or a random access memory. Storagecomponents suitable for tangibly embodying computer program instructionsand data include all forms of non-volatile memory, including by way ofexample semiconductor memory components, such as Erasable ProgrammableRead-Only Memory (EPROM), Electrically Erasable Programmable Read-OnlyMemory (EEPROM), and flash memory components; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCompact Disc Read-Only Memory (CD-ROM disks). Any of the foregoing maybe supplemented by, or incorporated in, specially-designed ASICs(application-specific integrated circuits). A representation of each ofthe various data structures and steps of methods described herein may beadvantageously rendered, e.g., displayed or printed, on a device, e.g.,a screen, monitor, or printer.

Although this disclosure describes certain embodiments and applications,other embodiments and applications that are apparent to those ofordinary skill in the art, including embodiments and applications whichdo not provide all of the features and advantages set forth herein, arealso within the scope of the disclosure. Moreover, all lists anddescriptions of options and alternatives are to be construed asexemplary and not limiting; lists have been used to aid explanation andare not an attempt to name all possible alternatives. The scope of thepresent invention is intended to be defined only by reference to theclaims.

TABLE I Sample of Information Output Dependent on Project Design Outputs# Typical Solar Project Development Steps 1 Site Conditions 2 DesignSchematics 3 Construction Drawings and Details 4 Part List 5 Bill ofMaterials 6 Construction Project Schedule 7 Costs Estimate 8 FinancialAnalysis 9 Energy Simulation 10 Proposal 11 Quote 12 Presentation 13Contracts 14 Subcontracts 15 Sales Order 16 Rendering 17 Statement ofValues 18 Rebate Application 19 Permit Application 22 Warranty 23 O&MManuals

TABLE II Sample Steps In Solar Project Design Step # Step 1 Gathercustomer information 2 Perform site audit 3 Select mounting system types4 Select module type 5 Layout modules 6 Design electrical system 7Generate bill of materials 8 Estimate system cost 9 Simulate energyoutput 10 Perform financial analysis 11 Create schedule 12 Generateproposal 13 Negotiate contract terms 14 Create final design 15 Createfinal drawing set 16 Create final bill of materials 17 Procure materials18 Award subcontracts 19 Finance projects 20 Obtain permits 21 Mobilize& stage project 22 Monitor project 23 Operate & maintain project

TABLE III Sample Feature Classes Class Object Can inherit from . . .Solid Obstruction Object Linear Obstruction Object Roof Object AntennaSolid Obstruction Conduit Linear Obstruction Drain Solid ObstructionEquipment Pad Solid Obstruction Expansion Joint Linear ObstructionGeneral Object Guy Line Linear Obstruction HVAC Solid ObstructionParapet Wall Linear Obstruction Penthouse Solid Obstruction Pole SolidObstruction Roof Hatch Solid Obstruction Roof Shot Solid ObstructionSatellite Solid Obstruction Skylight Solid Obstruction Sleepers LinearObstruction Stairs Solid Obstruction or Linear Obstruction Survey PointObject Tree Solid Obstruction Vent Solid Obstruction Walkway LinearObstruction Wall Linear Obstruction Water Valve Solid Obstruction

TABLE IV Sample Feature Properties Class Properties Object NameDescription Solid Obstruction Height Setback Type Subtype CoordinatesArea Linear Obstruction Width Height Setback Type Subtype CoordinatesArea Roof Height Setback Wind Speed Building Type Exposure Type Max RoofLoad Pitch Coordinates Area Antenna Height Conduit Diameter DrainDiameter Equipment Pad Height Expansion Joint Material Guy Line AngleHVAC Height Parapet Wall Height Penthouse Height Pole Height Roof HatchHeight Satellite Height Skylight Height Sleepers Height and Width StairsWidth Survey Point Coordinates Tree Growth Rate Vent Height WalkwayWidth Wall Height Water Valve Coordinates

TABLE V Sample Design Preferences Name Module Type Mounting System TypeInter Row Spacing Orientation Starting Point Off Set Tilt DirectionAperture Priority String Voltage

TABLE VI Sample Project Design Properties Name Customer Name ProjectName Project Address Zip Code Country Zip Code Country LatitudeLongitude Date Opportunity Reference Site Orientation (North angle)Utility Electric Tariff Energy Usage Maximum Demand Entity Type TaxStatus Tax Liability

TABLE VII Sample Module Properties Name Manufacturer Model Peak PowerRated Voltage Rated Current Open Circuit Voltage Short Circuit CurrentMaximum System Voltage Temperature Coefficients CEC PTC Rating HeightWidth Length Weight Frame Type Voltage Current Allowable Mounting TypesInterconnect Cost Front Glass Warranty Junction Box Output Cables RatedTemperature Max Load Impact Resistance Certifications

1. A method of generating a solar collector installation design on acomputer, comprising: providing a representation of an installationworksite, the representation comprising user-defined project stateinformation; applying rules to the user-defined project stateinformation to determine metadata about the solar collector installationdesign; using the metadata to generate a set of design exceptions,wherein each design exception encodes an exceptional condition due to aviolation of a software-encoded rule by the user-defined project stateinformation; providing a representation of the set of design exceptionsto the user; and for each design exception, presenting options to theuser to ignore the design exception or comply with the design exception.2. The method of claim 1, wherein at least one of the exceptionalconditions relates to one of the group of omissions by the user,violations of regulations, violations of solar collector manufacturerspecifications, violations of client requirements, violations ofphysical space constraints, violations of engineering principles, andviolations of company engineering policy.
 3. The method of claim 1,further comprising displaying at least some members of the set of designexceptions in a computer-based user interface.
 4. The method of claim 1,further comprising maintaining a record of actions taken by the user inrelation to each design exception.
 5. The method of claim 1, wherein anaction taken by the user in relation to a first design exception may besubsequently authorized.
 6. The method of claim 1, wherein ignoring afirst design exception may be subsequently authorized.
 7. The method ofclaim 1, wherein the options available to the user further includeexplicitly overriding a first design exception to allow the user toindicate that the exceptional condition is permissible.
 8. The method ofclaim 7, wherein explicitly overriding by the user in relation to thefirst design exception may be subsequently authorized.
 9. The method ofclaim 8, further comprising maintaining a record of the authorization.10. The method of claim 1, further comprising receiving from the usercompliance information sufficient to remedy a first exceptionalcondition and using the compliance information to modify at least one ofthe geometric objects or the project state information.
 11. The methodof claim 10, further comprising removing a first design exceptioncorresponding to the first exceptional condition from the list afterreceipt of user compliance information.
 12. The method of claim 10,further comprising recording the receipt of user compliance informationin a history.
 13. The method of claim 10, wherein the user complianceinformation comprises at least one item selected from the group of aproject property, a customer property, a design preference, a work areaboundary, and an aperture boundary.
 14. The method of claim 10, whereinthe user compliance information comprises a command by the user for thesystem to automatically address a first design exception, and whereinthe method further comprises modifying the project state information inaccordance with removing a first exceptional condition relating to theinstallation design.
 15. The method of claim 1, further comprisingreceiving an authorization of the design exception from a second userand recording that authorization as part of the set of designexceptions.
 16. The method of claim 1, further comprising receiving anauthorization of the design exception from a second user and recordingthat authorization as part of the project state information.
 17. Themethod of claim 16, further comprising removing a first design exceptionfrom the set of design exceptions.
 18. The method of claim 1, furthercomprising, in order, receiving a user modification to the project stateinformation, re-applying the rules to determine metadata about theinstallation design, detecting that a first exceptional conditioncorresponding to a first design exception no longer exists, and removingthe representation of the design exception from the user.
 19. The methodof claim 1, wherein applying rules to determine metadata furthercomprises generating a layout of solar collectors corresponding to theinstallation worksite.
 20. The method of claim 19, wherein the projectstate information contains classifications of geometric objects asfeatures of the installation worksite, and wherein applying the rules todetermine metadata further comprises generating a layout of solarcollectors corresponding to properties of the features of theinstallation worksite.
 21. The method of claim 1, wherein applying rulesto determine metadata further comprises generating metadata from atleast one of the group of energy simulation data and project summarydata.
 22. The method of claim 1, wherein the project state informationcomprises project version information reflecting differing versions ofsolar collector installation designs.
 23. The method of claim 1, whereinthe project state information comprises design preferences to be appliedwhen generating a solar collector installation design.
 24. The method ofclaim 1, wherein the project state information comprises classificationsof geometric objects as instances of feature classes and associatedfeature properties of the classified objects.
 25. A method of generatingterms to a contract for a solar collector installation project,comprising: providing a representation of an installation worksite in acomputing device, the representation comprising geometric objects, andproject state information; applying software-encoded rules to thegeometric objects and the project state information to determinemetadata about the installation design; using the metadata to generate aset of exceptions, the exceptions each encoding an exceptional conditionarising from a violation of a rule encoded in software and regarding theinstallation design, the exceptions providing information sufficient toidentify a term for inclusion in the contract; and generating a list ofthe terms for inclusion in the contract, where the terms correspond toone or more contract exclusions.
 26. The method of claim 25, wherein theterm for inclusion relates to a limited warranty.
 27. The method ofclaim 25, wherein the term for inclusion relates to a disclaimer. 28.The method of claim 25, wherein the term for inclusion relates to ascope of work.
 29. The method of claim 25, wherein the term forinclusion relates to a price.
 30. A computer-based user interface fordesigning a solar collector installation design, comprising: a userinterface representation of a solar collector installation design, therepresentation comprising solar collectors arranged on a surfacesubstantially according to project state information; a representationof a list of design exceptions, wherein at least one of the designexceptions corresponds to an exceptional condition related to aviolation of a software-encoded design rule by the solar collectorinstallation design; and a user interface control operable to allow auser to address the exceptional condition by interacting with the designexception, wherein interacting with the exception comprises performingat least one of the group of complying with and overriding the designexception; wherein the user may perform other actions in the userinterface before addressing the exceptional condition.
 31. The userinterface of claim 30, wherein the exceptional conditions relates to oneof the group of omissions by the user, violations of regulations,violations of solar collector manufacturer specifications, violations ofclient requirements, violations of engineering principles, andviolations of company engineering policy.
 32. The user interface ofclaim 30, further comprising a control operable to allow a second userto address the exceptional condition by authorizing the exception. 33.The user interface of claim 30, wherein interacting with the designexception comprises supplying data into a field of the design exception,the data being used to modify the project state information.
 34. Theuser interface of claim 30, wherein interacting with the designexception comprises selection of a control to automatically adjust theproject state information so as to remove the exceptional condition. 35.The user interface of claim 30, wherein at least a portion of theinteraction is recorded.
 36. The user interface of claim 35, wherein theportion of the interaction that is recorded is recorded as part of thesolar collector installation design.
 37. The user interface of claim 30,further comprising a control operable to receive an authorization of thedesign exception and record that authorization as part of the projectstate information.
 38. The user interface of claim 30, furthercomprising a control operable to generate a list of authorizations ofdesign exceptions.
 39. The user interface of claim 30, furthercomprising a control operable to generate a list of contract exceptionscorresponding to exceptional conditions related to violation of a designrule by the solar collector installation design, the contract exceptionsproviding information sufficient to identify a term for inclusion in acontract.
 40. The user interface of claim 30, where the representationof the solar collector installation design and the representation ofdesign exceptions are displayed simultaneously on a display device. 41.The user interface of claim 30, wherein the solar collectors comprisephotovoltaic modules.